URL/URI Standard Working Group #4

Transcript

all right thank you all for joining this is the fourth meeting in the direction of getting uri url standards moving towards final a quick recap from the last meeting in the last meeting key explained eip 4804 with a slides presentation uh greg who is unfortunately not able to join this meeting today um he had some question in the last meeting about this proposal like what would be the biggest benefit what's the main problem that dot is trying to solve etc so he recommended to reach out to decentralized projects for support and vital adoption and in response we see a comment added to agenda

we hope to hear about it the progress on proposal 4804 in a bit in the last meeting we did not get any update on eip 2400 but luckily we have the author here in this call so hopefully we will have some update from the team on that part and also a few weeks ago a discord user trezanya shared thoughts on this url uri meeting format that was added in the last meeting agenda but we could not get to that we ran out of time so maybe we can start from that i'm hoping that it will be a quick item to cover um so

hi um can you hear me yeah sure uh so i'm sort of coming at this from a perspective of like a just an observer um but after reading some of the url uri specification proposals um some of them like definitely are needed and that they're very general and um like you should need to have some kind of common denominator there but i'm worried about presenting like a useful specification for wallet developers to be able to present to users like enough information so that they understand what a certain

app is actually requesting them do so i'm suggesting that we should try to aim to have higher level url specifications that do more like high level actions like for example specifically requesting a payment in terms of a certain um asset type certain destination address within whatever roll up or whatever um and quantity instead of um sort of doing in terms of like low level call this function on this contract on this chain because saying a high level i want to be paid this amount here um is much easier for a wallet to

understand what it's supposed to do than saying call this function on this contract whatever um so if you have a higher level concept like that um it makes it easier um so like the example i gave in in the dock that i wrote up is uh say you have funds on polygon but someone wants to receive them on arrange from if you just say call this function on this contract in arbitrary um a wallet could go and figure out that function is going to end up doing uh but that requires extra heuristics which makes it more difficult to implement the standards and so and and there's cases where you could get it wrong like oh you think you're going to be doing this one thing but you

actually end up doing another thing so if you have a higher level standard then it forces everyone to think in terms of those higher levels including the wallet developers and also um since the other point that i wanted to include is from the the lightning network specifications um one of the challenges is sort of similar where they have lots of different kinds of binary data they want to communicate to users in a concise format and so i'm worried about misusing urls generally and trying to hack them to communicate this data when it's kind of inefficient and clunky so what uh the lightning invoice format

did um is it's all just binary the entire thing is just a binary representation and it's pretty compact and then you encode it in a opaque uh format called dec32 and so that can be turned into a url just by prefixing lightning on it and it's fine and it works like that but a lot i i don't think um tying ourselves to encoding the directly the data directly in the url format um is like really worth the cost of the added complexity and clunkiness um and thinking about like oh maybe we should just be communicating this data in a more opaque way that's harder to misuse and just saying everyone just rely on the library to decode instead of

you know trying to do it themselves i think that is probably a better approach um but i'm just some guy so i don't know what um other people's thoughts on that are if anyone's looked at that but that's basically all i had to say i think unless anyone has questions interesting okay um i i feel like i can agree with you on the uh encoding data as a more of an opaque chunk right um because i feel like with the current url specs um having written one of them um it is kind of frustrating to have to somehow try and make it fit into the whole http um like url version right where the

original um eip i don't have the number in my head real quick but um there's an eip that essentially describes ethereum colon whatever um and then we've kind of just started attaching prefixes and adding payloads and then defining that whole payload section but making it look similar every time and there's a bunch of discrepancies there um so i feel like i can understand with that i do not think i can fully agree or get behind the idea of um the the the vagueness there like i understand you'd want to be able to do send funds to address x on arbitrary or on polygon or on zk sync or whatever right um

but i feel like the more explicit variant if we could encode it in some better way um like a little more low level would be better because um again like the creator of such url or of such url that might potentially be in a qr code or in something along those lines right is usually trying to tell the wallet to do action x and to do it this exact way right and if you give the wallet more freedom of interpretation um so an example of that would be metamask current implementation of the um 681 spec right where they're only taking parts

like certain parameters they accept certain parameters they just don't filter for and they kind of just ignore which means we have different results on each wallet i feel like if we clearly just said this is the payload this is the address this is the function this is the amount and gas go that would be a lot better than if we said here's a somewhat version of do action x do that do that where the wallet still gets some decisions right because then it will be you might have different behavior depending on the wallet you feel what i'm saying yeah and so i agree that um like wallets need to be able to do whatever like they're so two parts right like i agree like having an explicit format where you say specifically sign this blob of data to this

contract to do whatever but um like if you're like a hardware wallet and you have like relatively limited access to the chain to decide what you're supposed to do and um like if the the hardware wall just presents you like hey do you want to sign this blob of hex it's kind of hard for you to understand what that blob of hex might do so if you have a high level presentation of what it's doing saying like oh do you want to transfer funds here to here to here um it's easier for the walt to figure out what to do than if it has this blob of data and needs to somehow like communicate back to the host and then that communicates to the chain to try to figure out what it's actually doing so it makes it harder for it to present a richer interface to the user

it's okay especially like if you have a limited thing there sorry go ahead sorry i i have a question uh so this url ur i working group is all about all types of urls not just the receipt warehouse so you're not just the receipt one that you ought to uh that you authored correct okay um uh because you were you're the author of 2400 correct yeah for transaction receipts right so um trey i don't know how much you've you've read up on the the url standards that there are right now because there are quite a few and they're quite uh some places overlap some places are there's discrepancies

but um an example would be like 2400 which ricardo correct me if i say anything wrong but um is for receipts so if somebody were to click that url or open the url in an app or scan the qr code or whatever um they are taken at least the idea is that they would be taken to um a screen that shows you the overview of that specific transaction and what happened there whether that be cached on the device or fetch from unchained um so that is kind of like one of the higher level actions we have an ad ad chain uh url we have a initiate transaction url which is pretty arbitrary already but it does fit in a certain like pattern right the http

pattern i mentioned before um so it would be nicer if we could take all of these actions which are kind of like a mix between high level and low level um because like a high-level interaction is the view of the transactions for example where like it is fully up to the wallet to say oh hey this function name was transfer so it was probably a transfer and this contract is erc20 so it's probably uh an erc721 and i should show the custom ui for that sorry in erc20 so i should probably show the custom er for that right i might be misunderstanding the use case of 2400 but my understanding is it's mainly for presenting information about transactions that already occurred right correct that's 2400 yes yeah so my concern was more about um with urls that

like adapt would give a wallet to say i want you to sign this transaction or or cause this event to occur on chain um so like i've i haven't read all of the oral specs but like high level actions like 2400 like yeah that's that's definitely good um and it's like much more unambiguous about what is actually presenting so um yeah i just want to like ensure that people like extend that thought process to um like comment like payment requests i think are like the current like urls that are available for them kind of clucky sorry go ahead i think that a good analogy to what we have now in web 2 is we have post requests so these this transactions request should be something like a uh

transaction request but of course we are not sending it to the server we are sending it to the uh the client to authenticate it so it's the totally different ui ux but the the tools that we these urls and url eyes are tools that the developers of the apps and wallets would use to coordinate what they want what to do of course that the main concern that we always have is is that people can exploit this to ask for the to fool the user somehow some some fishing i don't know but that that i think that the whole is much deeper there and we are trying

to fix that with decentralized storage and other processes that for example the governance and endows and all sorts of things to make to so the user knows that that that a system is outdated and yeah that that i think that that urls and your uris are are very important and they they can be useful tools i agree with you that there are there are other ways we can do with that but the the proposal here is actually to instantiarize the everything so the wallets can be consistent across each other at least in the important things

on on that note um there is a library made by bruno barr uh bring booner bar 79 previously worked at metamask now works at rainbow um the library is a little out of date now i've made a couple pull requests to it which are like we we got through reviewing them but then if i recall correctly bruno went on vacation or something so they haven't been merged so they've been open for a month but um those editions would add support for 2400 um for 5094 and uh better support for 681 um and currently metamask and rainbow as of my knowledge both use this library and i'm sure that there's probably a few other wallets out there

um let's see i have there you go that's the pull request uh and if you press that back to the code section that's the library as a whole um probably send a link to my fork shouldn't i uh let's have a look and some of the documentation has been redone but not fully um and the idea there is that we we now have one library that is now used across several wallets so that uh we could like a lot more easily make a developer experience where um as soon as we actually make such a payload right such as you suggested trey we're we're not stuck to this http spec but we're more um

like the first couple bits define the action the second couple bits whatever right like that sense um and be able to do a lot more compact um we'll be able to add that into the library here and then get every wallet to upgrade their packages and build their own uis accordingly but at least they'll have one standard way to do it right and we won't have to rebuild support across 20 different platforms that's great yeah i um i didn't read through the pr but it's good that there's a standard package for it i i'm not saying like oh you're not trying to do any of these things right now i just want to make sure that

people understand um like my perspective on it as someone that um might be building a wall in the future that wants to do uh like aggressive cross chain i i have another document that i was working on um describing like my i have some comments about the current state of wallet so uh but that's not ready for to be shared yet so i might have more right discussion give you later so now that you've you've sparked the thought of like the way that lightning does it right because you mentioned something about that um i thought back to reading the spec for how the lightning qrs work and like what is it bip uh i don't know something like that some one of the bips um about the the actual like how bitcoin and lightning do their

qr code urls and i honestly would have to agree that you know if we can make it smaller we we should um because the only hurdle here is the wallet and the wallet is the one interpreting the action and actually figuring out what to do with it right um so i suppose that makes me an advocate for rewriting the current url specs we have if we could and make them more compact in a sense um what are you guys thoughts on that how about you ricardo okay uh i i just want you to have some questions about the erc2400 so uh i noticed that that might might

have a use case where the wallet it's the receiver of the transaction is offline or doesn't want the transaction to be automatically submitted for some reason so perhaps perhaps i don't know if it should be included or maybe it's another url standard uh of the raw transaction so instead of publishing the the transaction and delivering the hash the [Music] the app could deliver the designed transaction back instead of automatically submitting it um i don't know if this is should be considered but yeah that's the only thing that that

i found here that i might add in this standard but i i really believe that should be another standard and only develop it with if really people here think that it's an important use case i think um if we want it to go such a way uh if we make some kind of rewritten like pure compact data right opaque data um url format where we are like making a transaction request we could probably literally take all that data change one bit around to now signify that it is a receipt and then

the wallet should just be able to read it with the exact same code and instead of showing it as a hey please make this transaction they'll show it as a hey this user made a transaction i think the only field we'd have to add or maybe add would be the sender address right because in a use case here one could send it to somebody else saying hey this is the transaction i'm going to make right but then again you're stuck with whether or not it would be valid and it actually went through no the dependent the sender address is the you can retrieve through the signature because the raw transaction contains the all the data the in the signature to

that transaction so you you only need yeah you would be just replacing instead of putting a hash of the transaction would be to put the right transaction there but yeah it's there there is a lot of concerns on that so i'm i feel that i should not add this use case here so just to keep it simple right right but if we're if we're going to do something like rewrite the entire idea of of urls right and try and make these um i mean my brain really here is thinking about qr codes because we want to keep them as small and readable as low detail as possible right because that improves

camera usability etc and a lot of things for users um how would we go about that do we i mean i'm sure we probably don't want to write an entire eip during this call but i'm sure we could come up with some ideas right let's say we started writing such an eip um what would be what would be key things do we designate a certain amount of bits do we do we take any inspiration from the way lightning does it what do you guys think so i i think that there is a simple way would be to have a standard that would specify a compact version of all the other urls so in the same file format that you have

json versus bson that is binary standard object you have the javascript notation object so on it's it's just a compressed version and then and maybe you can even use another compression algorithms like for example instance 7-zip i don't know anything right that that we wanted and then yeah we can do that in enlightening um the way it if anyone hasn't read both 11 it's you have um it's they're structured as like a tag which is a byte or a six bit type i think

and then a length that's a few more bits and then there's a number of bytes that follow that which is the actual payload and so there's a standardized list of types and most of the payloads are all just binary blobs anyways um and so that's kind of the most efficient way that you can do it without introducing ambiguity and like requiring parsers to be smarter than necessary so a few of the types are obviously like destination pub key there's a couple different like route hints which is a lighting specific thing there's a purpose field that you can have um in this case we probably don't need that but um and then obviously quantity so for what i think you would want for

like a payment request in this case um are the same basic ones about um destination address and quantity and asset type but as far as like optional fields like which roll-ups to say like well i want to use this particular roll up as the destination space or or maybe we could have multiple entry uh multiple instances of that where we could say like any of these particular different roll ups you can send it to me on um and i'd like decide that that's like a valid place to send the funds um so that sort of expands the possibility like i don't know how you would represent that in the url in an elegant way um and since it's already like in the

byte format it's all binary you don't need to worry about extra compression um since it's all probably just hashes or pokeys anyways those don't compress and so um you don't really get any inefficiencies there when you try to encode into the 32 so i think using something like beeson would be um or any kind of binary json would add a lot of like extra fluff to it that would make it less efficient okay let's uh chat about if we want to make it more compact right um and you think besan is not going to cut it i have the the both 11 i sent the link in the chat uh there we go difference between jason and bson as well

um four different um providers right for different uh layer twos and roll-ups etc um would we store that as chain id uh do we need more data than just the specific roll-up like will there need to be some kind of extra information depending on the roll-up and do we need some place to store that do we want to get together at some point and write this together or do we want uh just somebody to come up with a because i'm i'm totally down to sit down

uh and try and write a bolt 11-like payment encoding system for ethereum or at least a system that will be able to expand to not just doing payments but also a variant of 2400 and a variate of 5094 and a variation of 681 et cetera et cetera et cetera right should we do these things different yeah we can i think i think that that would be the best because then you have a standards or compressed standards and then you can go adding as they go time goes on as more urls appear you just append so we'll have something like uh do we want to stick with the ethereum ethereum

colon prefix then as well because that might that might add some ambiguity between the urls um yeah i i i i'm not like uh in favor of it i just inherited from other url standards yes okay so you're also not not do you ricardo let me rephrase that do you agree with the fact that the current way that we're doing our urls is a little clunky because of the whole staying in the http theme yeah i i agree but i i kind of like that

is kind of user readable but that is correct i i mean like and when i say see some urls i can read and then i like user readable urls and that's that's a technique on web development uh but i don't like when i have a url that is a lot of clunky data that i don't understand of course the transaction hash is impossible to hide but yeah what what else we we can do to make it clear that it's an iterative transaction to anyone that reads that information and also make it small so maybe right contract ethereum to eat eat

no no i mean yeah that could save some characters um i think the the way that uh bolt 11 is doing it if i'm not mistaken is there they're going like the ultimate minimum character route where um they're putting like lnbc as a prefix so it's lnbc then it's one as a 32 separator so lnbc1 is the beginning of all of their things and then there's a time stamp um there's a a payment secret like all this stuff gets encoded and they just put a character then a bunch of stuff and then another character or a character and then length and then a bunch of stuff yeah

do you agree that the urls should be elegant uh i think it's a tough one because if we make the urls elegant we can't make them compact most of the time right oh no for example why use like a number as a separator why not use like a dash or uh two dots i don't know oh that's fair that's fair but um like for the current example which really frustrates me about 681 um in the http spec when query parameters have the same key so if i have like some url question mark hello equals foo and by equals bar then that would work and it would convert that to an object where hello

equals foo and um by equals bar but if i make hello happen twice it will only take whatever the library decides first one our last one right and um the problem with that is that in 681 what's happening is we're using the type of the argument as the key and the order of the keys as the order which the arguments appear in on the function which makes it super difficult to actually parse and like requires a bunch of weird javascripts uh fiddling around to be able to parse query parameters because any normal query parameter parsing library breathe um filters out the duplicates which

is why like bruno bars library had some issues initially um and apparently no wallet ever tested a qr code or a url with different parameters but fine i guess or overlapping parameters um so that it does make it a little more confusing to write i'm referring to eip681 yes correct uh i think a url to that is in the chat otherwise i can drop you on as well if you want so so the the maybe the suggestion would be to not use them as parameters but as like well there's no space left in the url then

right or has path but the path is already taken up by the function name yeah right so it's it's a little difficult in the http spec and then uh 1594 which is uh like co-authored by me is a spec for adding chains through urls and that becomes difficult as well because you end up just shoving everything in query parameters and overlapping query parameters take care victor right which makes it very difficult and eventually you end up with a super long url that doesn't look that pretty either and like readability disappears as well

because the browser when you hover over url shortens them yeah but you know couldn't shouldn't they expect spec and makes invalid the urls that have duplicate parameters i mean the spec makes it valid but that means that like there's no library ever that assumed they were valid because http deems them invalid the original http spec so all the query string parsing libraries fail at parsing them correctly i see

yeah so i have a question about that 2400 discussion here are we currently even planning to move ahead with the 2400 in the present format or are we considering it to stay as is and come up with a new proposal with the improvement that we are discussing so uh um i can just i just have to make the commit to lascaux right that that that's you said okay i want to move forward on it but i i i i don't know if it should go to

lascaux because i see that there are there is a lot of discussions but if if we plan to like make make a compact version of the urls then i think that we can stick how it is now and maybe later we figured out this this problem off maybe this this formats can be temporary until we that that's the thing we want you to wait more to to discuss or do we want to implement it how it is so just a correction here uh to make sure that this proposal i mean like you and your co-author are interested in

moving ahead this proposal you do not have to move it to last call because last call is a stage where when proposal is all ready and we are only waiting for 14 days to get it merged towards final so the best thing for you to do right now would be to move it to the review status that will help all eip editors add more comments toward the uh proposal in the present form and uh that will also like invite community uh reviews this will give you the time that you are looking for and after a certain period of time if you decide to move it forward then we can move it to the last column oh so should i put in the status of the apa earpod as a review that's right okay then i should just send the the

pull request yeah that would be good and yeah look um as we are discussing that there there could be some improvement that we can probably use in the direction of creating a better proposal um in my personal opinion please correct me someone uh it should not uh stop any other proposal moving towards final which are already existing and has certain use cases so we can both work in parallel i i liked uh 2400 in its current state um i've written the library to read 2400 in its current state and uh as soon as that gets merged

uh the world comma well as soon as the major wallets upgrade but um the world comma will be able to use 2400 um all across the board however we are as discussed a second ago uh looking into potentially making a new eip that would be some composite of the ones we have right now um but rewrite them in a more compact um binary like format or or opaque format to an extent um the specifics of what this format would look like is i don't think we've fully thought about or decided on yet um so more information is needed for that i

suppose uh and i think it might be a good idea for the next meeting to start coming up with some ideas on how we could go about this and potentially writing uh some kind of eip or draft or something in those directions that we can all uh agree on awesome so eap 2400 is already getting support and you already have written library so let's let's keep that proposal moving ahead and about the proposals that we are discussing now i think it would be a good idea to maybe start a thread on fellowship of a theory musician to create a new proposal we can probably collect some feedback and thoughts over there and once that is uh firm enough to be converted into a draft

form maybe you can create the pull request does sound good well thank you i wonder if anyone else has any other comment and feedback on this topic before we can move on to the next proposal all right uh in that case uh look if you create a magician thread you can maybe share it with us and i will add it to the next meeting agenda doing it as we speak yeah thank you um one other thing we have another proposal for eight zero four is it yeah four eight zero four i think he is on the

call and he has a presentation slides google slides that he had added to the agenda i'm not sure he would you like to maybe talk about the development or the progress since the last meeting yeah sure um so uh can anyone see my screen um so i just share uh i prefer a few slides uh because like following uh the comments but on last meeting especially um i think people have some questions regarding the applications of what the erc4804 is going to do so here i basically summarize some motivations and applications and also i also summarize some upgrade updates that

i uh basically since last meeting roughly three weeks ago and so um so let me move on um so one thing that we feel that is missing in the current experience like a lack of decentralized presentation what it does is basically it can uh directly locate and render a web content generated on chain uh one example that we are seeing more application is going on is the nft svg files uh for example i've found an erc4a a8 that is uh discussing how we are able to create a composable svg nft on top of smart contracts

and also we found a project called uh cyberbrocker which they launched a few months ago uh we have enough we have nothing to do with the broadcast we just thought oh this is something interesting application that they are creating ft but they basically upload all the media data the savg layers on top of the ethereum and then the narrative is that because we have all the data put on chain so newton you'll never be worried about losing your media files when you buy ft the mt uh including encounter esc 7 2021 together with your media day files is on chain so when we read this

news oh this is really interesting application and so we take a look at their contract and see how it works especially how they're able to uh display the this on chain basically generated nft media files so um let's just take a random token id then we take a look the uh there's uh i think there's a mid image fill here and we're surprised they're actually still using ffs uh to tell the openc to say hey this is the image that you need to display uh when this uh um basic entity is displayed so say what

what why um so there's also a random method that tells that people that took id it will goes to cut their metadata contract and then in this contract that basically will have a measure that tells that basically they upload all their svg layers to this contract and so you have a bunch of layers method and then there's a way that can uh actually ren render the broker i think there's a message there a random broker and then you can even talk id then basically it will generate the svg file uh in an

iterative way so basically uh there's a position pointer that tells what's the range of this ft so just repeatedly calling this index pointer and then it will basically render these files one by uh all the files like just like binary and sequentially and then once it's done then we have all the ft that is svg generated change but unfortunately since we don't have a way to directly uh display this content on top of ethereum um so so i guess so they have to still rely on rtfs and said that once ipfs fix some data is

may lose may disappear then the user has to re-upload this content that store on exterior and and to do so so this is one thing that i feel like we should have something that can directly point to the basically the the web content that generated on ethereum and without using external external example services like ipfs or centralized servers so this is one thing that we feel we can do better another thing that we've recently noticed with charlie is writing a blog regarding um non-financial usage of blockchain uh one

part is using the um blockchain store as a block store and so that uh if he has silver comments saying that he's maintaining a copy of his blog on ipfs but it's very slow and then sometimes you might uh the files maybe jump off and if that is flexible able to jump the entire block about blockchain and that means you can say the whole problem um so um one crazy idea is that suppose we could we are able to dump all the blocks or fix some websites like ens unit swap on blockchain but how we are able to locate them

and be able to render them in a completely centralized way i'm definitely using example json us json rpc with curl core or is a scan uh it's now an app option for users we need kind of like a way that allows end users to directly access the blocks access the generated svgs uh directly on chain um so this was the major motivation of eic ways so far basically it's a hd ply like url to locate the uh we call the webster resources that is hosted by a smart contract so it's very similar to um

http uh which we use the raspberry schema here and you also just registered this raspberry schema on iana and and then it has a a little bit different uh is that using the contract as the instead of host which here we use in the main service from ens and then corresponding uh it will points to a contract that hosts the web stream resources uh instead of like the address and it has a bunch of paths that tells you to which measure to call and what kind of the parameters which can be also written in

main and also the expected return types because we have no idea what the uh contract a return time is uh if the return type is is not given then it will by default tree this um uh the return will be uh bytes and then we will pass it as a web content like svg or html uh we also have a gateway that is able to access this urls uh which already installed in my uh this firefox uh which uh to support the web3 link to the gateway link translation and the purpose of this url is to not we do not require a wallet to access the

content so it's basically it's just putting this url to the gateway it's like ipfs i type something in the gateway then it will automatically retrieve this uh data uh from the blockchain and then return and display ran into the browser um so let me give a couple of examples so for the cyberbrokers we take a look at their contract and then um so we write write a simple contract which basically has one method called random broker we've taken a token id which will recursively call their method uh which is the regular method and then be able to concatenate all the

basically binary data they return and put return with a single svg binary data and then we register this exclusive cyber brokers the bns name and points to this random contract that we uh deployed so now with this uh this thing now we are able to using the erc4042 directory for example random this um this svg directory um so that it translates to a gateway so i just replace the gateway with f3 and tells taiwan to call this counter its method and the trip id

without by specifying the return types then we will treat it as a web content and the browser will automatically detect this and then display in svg image format and so all these things are generated using the smart contract and display directly uh on the browser so so this is one example so we hope that with this standard uh for the project they are using the composable svg onto blockchain now they are fully be able to replace the ipfs or any centralized address to the proposed elc4804 addresses with the corresponding message to how to call the contract and render it in a

decentralized way so this is one application another application is a personal blog study website just like the test blog so we make an experiment we download all the vitalx blocks by including 500 files with 36 megabytes data then we upload all the files uh to a special contract that we create that is able to host these files and they are uh the path in all information and on wrinkly testnet and then we are able to redispel uh by a form for that matter um that's quite different because we want to support directory structure and absolute

relative parting so for example here is the erc404 link which points to the basic special contract that we created and which will basically goes to the retarding homepage that host it on the winky beam and i can go to the example the article that i just browse and that is also basically uh store on top of blockchain but here we see that here it goes to the uh basically additional basic paths that will be passed to the contract including the core data

and the good thing of this is that it can support relative particle so for example let me see this image the image in the basically in the original vitalix file is a relative parting which contains the parents parents parents directory and images and some files and in browser it will automatically basically given this it will automatically translate according to the url uii specification translate to the corresponding caller pro protocol specific relative passing to this link and this link will also uh yes

um so um so it will also be translated to uh basically uh core data um uh so i think we can have the questions about about bodies so about the gas cost um so it will translate to the core data that will basically find the image in the the roof roof directory and then this could display it correctly so there's one question because saying that this gas uh meter of the highway uh there's 23 eastern store on the serum and that's something also we take closer look at several brokers what the

um what the what they have done and basically uh one optimization actually we also have done is that is be able to store it's using a contract instead of using using the contract and instead of using the uh storage local storage um then and then it it will roughly save roughly one third of the gas cost uh in just native ethereum storage case but definitely we are thinking about in the future yes in the future of issue

and then we are able to use in the shoddy day blocks um all even with the serum for example some l2 scaling solutions that we are able to write which is friendly uh for decentralized storage then we think we are able to save this cost even even dramatically maybe 101 to 100. yeah and so this is something like crazy ideas say hey if suppose now we have a blockchain that is able to have this capacity now they are acceptable to a lot of interesting applications so here i will give a

interesting application is that we are able to create some implication that is more user-friendly um that means that the user is able to for example to for example read the blocks [Music] yeah but that that means that uh they either will rely on customers if we really want to save in icfs that means we either rely on centralized server like some universe xyz or we need some uh cri like some of what we talking is doing um so um and so here i give example that we are

able to create some decentralized applications that um without for example we use it without using any ci and also [Music] so for example here i can create a blog i can upload a blog and for example this is my first world which i will basically submit a transaction and then yeah um so now i am able to

have to create this block without just using wallet without any other example ci other options um and then i can browse it i actually have browsing this this block doesn't need any wallet because it can just using the web3 url to directly access all the content um without any wallet but if i want to modify this car this this block then definitely i need to have a wallet that helps me to submit a transaction and then i can modify it and this will update to chain and then it will call the erc4804 url and then retrieve all this content back

and so with this we are able to create a lot of applications without uh for example cis um but and without for example uh web servers and so um so a couple of disciples that uh so it was originally um we um we want to maximum compatible with http uh so that we can use the same including decoding scheme and query fragment that our current http already supporting one important feature that we want to

support is absolute relative party so we are able to uh for example uh support composability of these resources that are including in the defining in the eic4804 we are hopefully it's employment readable and actually this is also a property of http for example we are natively supporting the name resolved by name service currency ens we also want to be the simple um [Music] uh it's maximum likelihood detection uh for some common types uh it can be integer and it can be like you in 2056 and they also we have

the option to accept the pool parts and query so that the evn just uh served as a cgi uh script um the logo is that we are not planning to sign a submitter transaction uh just like yeah six day ones targets uh for example for value guest email guest price we are not really in this moment um so uh the couple of more details um so for example right now it has automotive to resolve the resources uh in auto mode that the standard will translate the path and the query enquiry to a standard solidity contra avi method called

for example it will translate the master and the encroachment argument to the corresponding message id and then also be able to find the corresponding address to the resolve the address from ems and then put it together in coordinator and to call the contract and if there is no corresponding return types given that you will just pass this back contact um okay so before so probably i can just go quickly speed this um so um there's a couple of recent updates in last two weeks uh there's a couple of investors uh investors so the developers are asking the stability of the standard and say whether that's

to uh start a service to support it and they also a casa uh saying that how we are able to generalize this particle to multiple chains like including solana including phantom um others and then also regarding the com some link space reserve assignment for this uh url and then also asking questions how you're able to ensure fully trusted access uh in in case giveaway is lying and also how how to have some question regarding uh what the input argument should be and then how we are able to support additional features like historical data

query by adding the block number thank you thank you for sharing all these information uh and uh i have a question for you maybe i was looking into the discussion to link that is provided here as you mentioned that there are quite a lot of interest and comments this proposal has received there but this proposal is also in the draft status yeah yeah i wonder if you think that it is ready enough to be like getting more uh comments feedback on it maybe you would want to move it to the

review status oh sure yeah that's that's the plan uh that's also something that i want to share today but uh but it's just i feel like to me like something that um i think doesn't change the major components of the standard so i think i can just move it to the reveal status up to the basement all right um i know we have markers although but he is on mute please signal us is there any anything need we need to get it done from eip side before moving it to review i'm sorry yeah asking question i know

okay fine no the question was for eap editor but i just remember that this is an erc so maybe micah may not have looked into detail of the proposal however i will if you would create a pull request we can probably bring this to the next tuesdays meeting discussion which is a eip editor's apprenticeship program but we generally try to look into the full request of all erc category of proposals and if there are any further feedback we can share it with you but it's totally up to author as far as i understand if you feel it is ready please make a full request sure sure yeah all right do you have any final question

uh for the group that you would like to get answered before you can make the pull request um i don't think have uh other questions um yeah i think there are a lot of comments but i don't have time to go through all the other questions not a problem i will try to uh like capture the comments share here in the text chat here in the working document that we are sharing in every meeting agenda and will bring up this eip in the next meeting for further updates right well thank you everyone um this was a nice meeting i know we did not get the resolution to trey's comment and trace suggestion maybe we would hear more

about it in fem link that is created or in future meetings i think i shared most of the points i cared about i can add more comments into their magician's post but so i think i'm all set all right well thank you so much um it looks like people are divided here some some may think that there are certain proposal in which getting into details and lower level may be useful however there could be certain proposals which may use on the higher level instructions not getting into the details so we'll see how proposals are being drafted and proposed and definitely up to eip editors to make the

decision well thank you all for joining us today and uh we hope to have next meeting two weeks from today that is july 25th the same time thank you everyone have a good one thank you um trey could you reach out to me on the uh ethereum wallet or the uh ech uh discord so we can chat a little bit more about um compacting it etc yeah yeah of course sweet awesome thanks thank you everyone thank you everyone