URL/URI Standard Working Group #1

Transcript

all right thank you everyone for joining uh we may be expecting a couple of more people to join in i'm just gonna share the hackmd file that i have i probably have shared earlier with some of you and this is just a list of proposals which are available on eap repositories for uri or url standard i know this is the idea of magnet to have all these people in a room and we can probably talk about standardization process or how we can have one good standard available for uri and url so matt if you would like to maybe provide a brief introduction of your thoughts and then we can take it from there sure

thanks a lot for coming on here i appreciate everybody's time i have to say that this is like a bit outside my domain of experience but oh hi pedro um but i just wanted to say that it it feels like there's a lot of different standards that are started starting to bubble up now related to urls uris referring to information on the ethereum blockchain and it's not clear to me how much overlap we have on these types of things and maybe the outcome of this call is that there's really not a lot of overlap and um people will just keep doing their own types of things

but because they're so closely related it feels like having a slightly more monolithic standard here could be valuable rather than fragmenting this across like three four five different standards that are referring to individual things so hey micah so i feel like if the outcome of this call is that we can at least just figure out like what exactly are people doing what what do they want to accomplish with these standards and how can we group these in a way that makes sense and then figure out what applications and what um what libraries are going to need to

support these things that way we can work on making sure that those things are upstreamed into those because it's you know it's something that we've seen before where people come up with good standard ideas but they don't ever make it into like canonical upstream sources and so like a good example is like if you make it change the rpc but it never is upstream to web3.js or ethers then you know more or less you didn't make a change to the rpc because that's the interface most people access so i think that you know if we can come up with those two ideas if we can figure out those two areas that would be great hey micah uh the two sentence description of what we're here for is to figure out how much

overlap there are on these url ui standards and figure out the best path forward for not having too much duplicate work sweet um i think from my understanding right now there's a couple schemes out there uh there's the ethereum scheme the dap wc and ethpm or ethempm right um so under dapp uh bruno renault bard 79 uh has made a url for dapps in general to basically have deep linking into mobile wallets so you can

that way open up your mobile wallet um wc is for wallet connect they have their own uri scheme that they use for all their fun stuff um and that is like wallet connect specific actions uh there's the ethpm scheme so epm colon slash slash uh which i think is to link to ethereum packages and there's anybody use that that's i don't even know okay it's the first time i'm seeing it um and then there's the ethereum scheme which as of right now if you do not put anything behind it uh so there's 831 which defines that there's just ethereum colon

some prefix dash and then the payload um the current prefixes that are in use are the pay prefix if you put nothing or you put the pay prefix it's a 681 so it's for transaction requests so you can request a payment or a specific transaction to or interacting with a smart contract um let's see uh 2400 or 24 yeah 2400 describes ethereum colon and then as prefix tx um to be able to link to a transaction so say you had a vending machine or some appliance that interfaced with ethereum uh they can give you a link back to the actual transaction that you

just submitted or to a past transaction etc or we can in our browser link to transactions without having to specifically link to ether scan or polygon scan or whatever um so it's ethereum colon tx dash transaction id and then at and then the chain id and then some extra information and then um the one that i've now proposed together with a few of the co-authors is 1594 still an open pull request and that is for actually switching to networks because what i realized is i'm working on a little project in ethereum vending machine right it's an appliance it needs to interface with your mobile phone somehow so we're using qr codes for it

and what the situation is is that like the ethereal parser npm package uh made by bruno which is funnily enough the guy behind the dap scheme um he was both at metamask and he's now at rainbow uh he wrote each url parser and it only kind of supports part of 681 like it doesn't support any of the like calling functions on a smart contract except for transfer um it's kind of hard-coded in there so i have spent the past week or two uh upgrading the ethioreal parser npm package and it is now fully compatible with not only 681 but also 2400 and the currently um open pr for 5094.

um and it supports all of them and it's migrated to typescript and it's lovely and it works uh and i've been back and forth with bruno on on you know changes that he wants to see and then you know making sure that all happens uh however the issue that i noticed with the mobile wallet is that i'm deploying my stuff right now on polygon to test everything out which obviously is not eve mainnet and scanning a url or uri if you will using metamask or rainbow which parses it through ethereal parser appears to fail if you try and use a chain id that doesn't exist yet right that hasn't been added to the mobile wallet so if i haven't added polygon manually typed it out everything

to my mobile wallet then i simply can't make a polygon transaction um so the idea of 5094 is to kind of mirror the rpc variant because you know we needed a url standard as well um to be able to use it in qr codes where i can just put a sticker on the vending machine that says add the polygon network same way we have the button at the bottom of a polygon poly scan um to add it to metamask for example right and instead of running an rpc call in this case there's a url ethereum colon network add and then all of the information for the network itself so the network name the currency name decimals etc so that's kind of the the situation

there thanks thanks for the overview that was really nice so your particular use cases you want to create a url that also includes all the information about what network to connect to basically payment requests there's only the actual chain id right and that's not gonna get us far that's not gonna give us an rpc endpoint or a name or whatever so okay so maybe the the first thing we should do like after the summary of of everything that's out there is go through and actually list all the use cases people have as opposed to the actual standards uh so right now we have like network switching um what other use cases do people have that they want to talk about if you don't mind like yeah actually i'm thinking the question

because like i saw like there's a seminar uh comments regarding the different type uh distinguished use cases like network switch switching and also uh fixed amount of transaction receives and also um the apps so i feel like probably we can put two categories kind of like a core eips versus erc which is one one type of uil is help help the basically the users to locate uh fixed one read and write the basically resources on top of uh ethereum for example it can be a request a transaction it can read a state or read a maybe block or read for example any

result that is returned from smart contracts and that's something i feel like it's highly correlated and probably we can put it in one vip and probably there are also a couple of sub uh other types of uh come like erc that uh request come like for example the new network or for example uh add on a d-app link so that it can uh designate what kind of network id is uh this is kind of initial thought after reading all this erp erps yeah any questions um i mean i'm not a fan of network searching

obviously but isn't it better that we just have optional parameters to an actual action you know because it would take one qr code scan i know it would become like a quite a significant qr code you want to resist the data in a qr code so it's readable but for example you have chain name rpc url rpc url seems relevant but then should wallets just do most of this work i feel like sometimes you put too much pressure on dap developers and then the

wallets do the least like you're giving the chain name name symbol decimals explorer url all of it through a qr code when you know a single chain id should be sufficient uh i mean it it's it still depends because then you're relying on on the wallets to pick what rpc end point you're going to use right so then the wallet becomes the deciding factor on what rpc endpoints get used um with 5094 right now you can even give a list of rpc endpoints but the i mean like you suggested we could hypothetically speaking amend 681 right uh the ethereum actual payment standard

and that's already final and add query parameters for rpc url etc etc etc however that would make the qr codes like you mentioned really detailed right super long i think you could just feel like the rpc url would be sufficient yeah because you can get everything from that um i mean then you still have to add an rpc url to your thing so it's going to add more complexity to the url in overall right because it's going to be ethereum pay dash whatever contract you're interacting with slash whatever function you're interacting with then gas price gas limits and a gas estimate as well as value and then every argument

you're giving to the function which probably also if it's like an erc20 transfer contains another address right so you already have a very long url that's already very detailed and requires in my specific case um but i can see this in a lot of other cases as well requires more details so if you're going to print stickers to do this they're going to have to be very detailed if you're going to use a low-res display you just you can't right yeah i guess i'm not quite understanding the motivation for including rbc endpoints or urls in this um standard because

in my is is that in 681 or is that understandable you're proposing uh 681 doesn't have anything currently what i'm proposing is making a specific url dedicated to adding a network so instead of it being pay dash it is network dash and then the network information so you can scan a single qr code that you can attach to wherever put it on a site whatever to just add the polygon chain or add optimism or whatever which would do the equivalent of pressing the add to metamask button at the bottom of etherscan for example what flow are you imagining with this because

the way that i interpret these flows is that the wallet should really be the one who decides what network it supports because right now there's pretty good overlap with eth and polygon and optimism but that doesn't necessarily have to be true and so just adding a network and assuming it has that same interface as another network could be a could it cause problems what do you mean with same interface just these networks assume that there's a specific interface for interacting with the network and that there's certain assumptions that are being made um i mean you can imagine that a network performs completely differently i mean

there's already these differences with l2s right now right like if i submit a transaction to an l2 then that transaction actually isn't posted to the mainnet and so there isn't very good guarantees that it's actually going to go on chain for several minutes and there's lots of just small things like this that walls might want to interpret in certain ways and so always just assuming that it does the same thing as mainnet does might be problematic and might cause uh users to you know encounter strange issues or strange behavior when they add some more esoteric side chain or l2 so this is just all to say that it feels

like a the wallet should dictate what network it supports and if you try to use a qr code that doesn't support that it doesn't support then that should be handled you know in a better way like crashing is obviously not an acceptable way to handle it that's what's happening currently right well how about this proposal this proposal kind of fits uh your requirement right because you as a user would scan the qr code for network ad before doing the pay correct so i end up being the same at least you fail for a different reason you know why you're failing

while the other one is just like randomly failing and who knows why the ideal flow that i'm imagining here and obviously it's not the most ideal but it is the best we can do with the current situation of 681 is that um a user would walk up to the machine they'd like to interact with or the site that they'd interact like to interact with assuming they don't use wallet connect um and try and scan the payment request url or qr code and then their wallet should give an error saying unknown network or please add the network with this id first right and then the user will probably look down realize that there is a little pop-up at the bottom of the

screen that says to add network scan this qr or click this link and then the user can scan that to actually add the network so i'm i'm simply making the equivalent of the rpc function to add a network but then in url format if that makes sense so i think i think it does make sense but i'm concerned like i'm already concerned with the rbc endpoint friday network and the reason is in that situation you described i really don't feel like that user should be adding a network from a vending machine like either you are familiar with the network you're interacting on or you're not you should go research it and like fair normalizing this behavior of getting users to just like scan qr codes in a subway and add them to metamask

feels very dangerous and ripe for abuse and so i'm very hesitant to to normalize that and make that like an acceptable thing i feel like you should tell the user hey you know we're on polygon you need to go get some polygon eth you need to go research what polygon is then you can come back and use this vending machine not like hey this is a vending machine sign up here to get your free candy bar but most most wallets get mad at you if you try and add a network and you use the incorrect information right and worst case scenario somebody adds a third party endpoint i mean you you have a chain id and you have an rpc url i don't see how this could go wrong the worst case scenario

somebody you know who makes this malicious qr code adds an emoji next to polygon mainnet right matic mainnet so i think the the worst case scenario is um i've never used like hypothetically i've never used polygon before so i go up to vending machine it says add a polygon i scan a qr code to add polygon and i buy my candy bar or whatever i now have polygon like oh polygon is nice i'm using it and then i go do some other stuff i'm polygon but lo and behold this whole time not actually talking to a real polygon rpc endpoint i'm talking to some malicious endpoint that is then forwarding some of my requests to polygon and then capturing some of them and doing bad things letting me back data back um making me think that i'm going to do something that i don't intend to do um

stuff like that like i've basically just added some something i got from a qr code as an authoritative source of information about the polygon network but i have no reason to believe that is actually the polygon network i'm talking to it's just you know some do it on the internet or in this case at that point you'd hopefully have your wallet either interfere your wallet have a pop-up when you scan the qr code actually showing what you're about to add as a network and i mean it's the same situation when you go to any website that says add the polygon network and you just press the button there right yeah and i think that's terrible as well like to be clear i'm not saying just your what you're proposing is bad i'm saying like this normalization of people adding networks without knowing anything

about them i think is bad for the security of end users like right now the users that are doing this are you know apes and dgens and whatnot and they know the risks that they're getting into i'm much more worried when you get the mom and pop that is normalized into oh you know if i see a new network i'm just supposed to click add and those are the ones that are going to get scammed i'm concerned about so do you have any better solution in mind at the moment because i'm fully on the same page as you i just personally i don't see a better solution i think what matt was getting at i think what matt was getting that is the the best from a security standpoint solution which is the individual wallets add support for

networks natively and you trust your wallet presumably because you're giving it your private keys and so they are delegating authority to you know okay we we met a mask assert that this is how you access polygon you access it through this inferior link that we have baked in or you can add your own manually but that's a an advanced use case and then in theory you know the wallets add a bunch um this i recognize this does make it hard to get new l2 adoption because you need to sell the wallet first or you can only sell it to advanced users but the trade-off we have to make here that i don't see a solution to is end user security versus ease of adoption and i tend to fall on security just because i i worry not

about the current generation of users i worried about the next generation of users who are just going to get just destroyed well but the the problem is already present with the rpc this uri is not adding the problem and i don't even think it's extending the problem because it's going to be the exact same pop-up right when you scan the qr code or you receive the rpc request you will get the exact same pop-up to the user which will provide the exact same information of chain id name and everything yes so i agree the rpc is bad as well i just don't i'm not a fan of making it

worse i'd rather talk to wallets and can tell them just to remove that rpc rather than adding even new and simpler ways to do the same bad thing like i consider users clicking a button to add an rpc with no you know like you know when you said metabolism they go through like you know seven steps warning you about all the things that can go wrong when users click the button to add an rpc everything seems to just work and it's one click and it's easy and users are not aware of the dangers that they're getting into and that concerns me outside of chain id is there any way we can validate that you're connecting to a legitimate not like interfered with node probably not right

the only way you could do that is by sampling and you'd have to sample multiple rpcm points that you could think you could trust but even then you can spoof the response of the json rpc which is what i do yeah when you still met a better mask you know they give you the inferior one and you're implicitly entrusting in fear by delegating your trust through metamask um if you ask the hardcore security people they'll say no you should run your own node i guess the only way you can actually trust this um there of course is a spectrum between you know just subway rpc endpoint and run your own node and inferior somewhere in the middle um but you are correct there's there's no

way to authority to gain that trust other than through an existing trust network which may mean you're running your own code it may mean talking to a friend who you do trust about all these things who tells you oh and fear is trustworthy or here's my node you can borrow it etc the further away you get from that trust network the more at risk you are of someone man the middling you basically well something else works with dns and i think we should be using registries more you know we currently have one big ethereum or evm registry and people should be taking advantage of those even in the case of the rpc endpoint one one thing worth noting too here is

like i think we're complicated this is like two separate issues right it's like one is the standardization of just like some url format the other is what like what does a wallet developer need to make their experience better i think mika kind of hit good where it's like this makes wallet developers lives easier but realistically hey how many evm chains are people actually adding all the time and b like if that's the pro if the problem is the lack of evm change the wallet developers should either enable advanced functions like in metamask where you can just create an rpc or they should just be updating their app more frequently like i just don't see

a reason for exporting that process because like yeah like mika said if you're at a vending machine it's like oh add this random network and you need to procure tokens and stuff to begin with or bridge them over it's already like super risky at that point and realistically you should be saying why haven't i heard of this l2 and like where like you know there should be a lot of questions at that point and if there aren't we're not educating our users in the right way by allowing it i mean you might have just not added your mobile wallet uh the new networks yet in my case i haven't gotten added yet so you know yeah but like why it doesn't like the wallet should add the standard yeah all i'm saying is like well i

should be adding the standard l2s you know that's my that's my leg yeah it feels like there's like a spectrum where we can push more of this work towards developers like on the application side and then the spectrum where we push more of these things to the wallet developers and it feels like we are not pushing things hard enough onto wall developers we're accepting that they give us like basically the bare minimum to interact with these chains and then we do everything else and it kind of feels like that's not the best approach yeah and and also on that note i mean like at the same time it's kind of like you know with really it's like who are you building your wallet for the generic user or like somebody that needs to do like more advanced testing or whatever it is and it's this feature seems like it's really

helpful someone like us who might be wanting to test networks all the time but not super helpful for the generic user as it just like compromises too much security i want to take a step back quickly we're kind of running up on time and i don't want to keep people too much over um so the people on this call probably have a pretty good perspective on what types of things are lacking in this you know sort of domain of urls uris is there something that we should be doing to more actively cultivate standards in this area

like what's the you know what's the best way to improve you know the situation that users are interacting with and like in this example where we have this in the cip to add um actually new networks to wallets like this is obviously important given the situation where and where wallets are not probably doing what they need to do like how can we then like transition to making walls do the right thing so you want to instead of talking okay so we've we've agreed that this is just a uri format right and that's that and the greater problem at scale is we need to like tighten down on wallets and go hey you should take some

responsibility for your users and like make sure they're safe um how do we resolve that i mean we'd need some way right because it would be sketchy if wallets started keeping a list of trusted rpc endpoints because then we're back to centralization right they already do that they already do that okay we i wouldn't say we're back to we are still in the same situation yeah right so we're looking for improvement on that you you're giving full trust to your wallet and so i think that you know the things that you've already decided is okay like them deciding what rpcs you interact with is you know not as bad as what other things

they could do it's not the biggest concern yeah fair i don't know sam do you have any thoughts on things we can do with wallet teams to to talk about these situations um i think it's just important to include them in the discussion of what's possible um and what they'd like to see like i i definitely think having a registry of of endpoints that wallets maintain might be a good idea but that's about as far as i thought about it so like some sort of spec that says these so this is the wallet name space and then linking train id to a list of

rpc addresses and some basic information right so i liked i have a fan of the way uniform handled this with token lists where it's a decentralized system you can pick your list and the app can support the list but you don't need to couple the two and so i might use metamask but i might use you know the sam wilson list of rpc endpoints instead of metamasks yeah that's that's a great idea not not giving me a list but um using the uniswap like tokenlist model i mean isn't that essentially what we have isn't that what we have basically now though it's not a list but you have the

ability to configure any specific one yeah so they deal with i mean uniswap originally was that right you could manually add any token but people were frustrated because you know there's so many tokens and adding them all one by one was a pain and so they made token lists which is now instead of adding each token individually you can add a list of tokens from somebody you trust and that doesn't have to be the person whose app you're using it can be someone different and so your you know your wallet is one entity and they give you a default list maybe like minimas gives you inferior because it's consensus and they own both um but you can say you know what i want to use all the tok all the rpc endpoints as provided by you know rainbow wallet or whatever or sam wilson

or wherever you're getting your list from and now you have fully populated lists that it's not just in fura you know it's also a bunch of other places well this sounds like something we could bring up with the all wallet devs and get a uh an eep together for creating that yeah sounds good do you think that means do you think of the meanwhile 5094 is a temporary solution if you will i mean yes there's going to probably be sketchy subway things but there's also sketchy websites where you press that button and it triggers the rpc endpoint right yeah like i said i would rather spend our efforts trying to get people to remove removing that from wallets rather than making these here that's my

personal deal like i want to go the other direction right but that's going to take time yes and i i do not want to go towards more or towards less secure while we are working on going because these are opposite directions right either we go towards make it harder to add rpc endpoints from random places on the internet and random places in the world or make it easier to do those things um what 59 informants describe describing if i understand correctly is let's make those things easier and i'm saying no no we should be making them harder like these are in tension with each other you can't really do both you do one or the other 1594 is simply a mirror of the rpc version like the javascript api version

that already exists right and we should get rid of the javascript api version and not add things that use it okay all right do you think they're there do you see how there could be issues if we had a qr version or like link version if you will uri um for adding one of those trusted lists because then you're still in a similar situation where a user gets told hey just add this list thing to your metamask wallet ta-da right yeah same thing so the way unit handles this is they don't give you a list they give you a place to put a list and then you it's up to you to go find your list and then they give you a link

to a place that's got like 100 lists lists listed and you can pick from them um like they they give you a breadcrumb basically on hey here's how you can get started but they don't automate it right which is i think the uh yeah exactly that's that's the key they it is up to the user to go find the list um and we don't want and specifically we don't want giving people a list because that's delegating trust to the person who gave you a list which is probably not someone you should trust like anyone anyone who tries to give gives you a list is probably not the person you want to get a list from right okay we're a couple minutes over i've got two main action items that i wrote down one is talk to wall it's about just

properly supporting rpcs and considering supporting some type of rpc lists that way we're not coupling those two as tightly together and let's do some work on trying to remove this rpc endpoint that lets users add new rpcs to wallets is that roughly what we've come to oh and schedule uh the next one of these working group meetings so we have a deadline [Laughter] so i will i will acknowledge that you are going to be fighting a very very hard uphill battle to remove that rpc endpoint yeah right um like

if if for those of you not aware the uh cryptocurrency depth space likes to move at breakneck speed ignoring all security concerns yes and that is uh that rpc endpoint was one such thing where it was like hey we want to get lara 2's working before they're decentralized while they're still sensorable while they're still centralized well people can still steal all the money before they're audited we want to get them into user hands right now with a single click and their pc was added okay i'm bitter so i i presume that this is going to take a fair bit of time um like this is not something we'll have done in the next

like week or two right and then we need wallet adoption as well and it's just going to keep going and going and going and then eventually we'll reach the effort of removing add to metamask from ether scan and polygon scan right and the whole thing like chainlist.org or what is it something like that uh tokenlist gameless.org lists pop out here okay it's like these would then completely disappear right no they just become a token they'd become a a list that you can subscribe to right yes so you could you could subscribe to chainless.org like that could be your but then you get your list of changes hopefully it's in your wallet already right so most users won't even use chain list because

they already have one game given from metamask they'll have the metamask list but then they will have the option of switching yeah exactly yeah yeah but let's be real most people don't change their default browser and still use safari or google chrome or edge if you will um depending on the device so yes so so the way the way unisop handled this which was um good i think is their built-in list was incredibly limited it's like die usdc usdt and east and west i think or something like that and then it's up to you if you want more and so in a perfect world the

uh there's no there's no perfect world in one hypothetical world the wallet comes with a default list that is fairly constraining and then any user who wants to do anything more would go find a list and add it like chainlist.org they'd use theirs or something there's another alternative world where metamask includes chainlist.org or includes their own but it is very thorough and complete and you're totally right most users will not change it um which is unfortunate because it just means we're delegating more and more trust to the wallet that being said the wallet is at least someone you have trusted your keys with and so right they're already have so much power it's perhaps not that bad of a problem if they also have the ability to manipulate you

so here's what i'd like to propose and uh give me a moment to like properly put this out there um i really want something like this and i understand that if we currently put it on the track of making the better version of this right it's going to take a fair bit of time um i think what what is very possible is that we actually don't get scared merge 1594 but we add some kind of clause at the bottom that says that it has an expiration date and that it is awaiting for override from a future eip that we will be working on and getting implemented into wallets so for the meanwhile that is a feature

um because again it's just a mirror from the rpc feature that already exists and then as soon as we are ready to replace the rpc feature we can also immediately throw out 5094 right so essentially it says hey this is here temporarily just to add support it will be deleted in the future if that makes sense so i i don't think any eip editors are going to stop you from merging that eip even if you don't agree with it but um i think it's one of those things where if you want to build it for your dap and convince wallet developers to do it you you certainly can but i don't think it's something that we should like actively try to

encourage because if applications build on top of it then you get a bunch of momentum to to keep it and then as that momentum builds up it becomes harder and harder to remove it so right now there's like let's say you know 10 apps that use the rpc endpoint and 10 apps that would use the url well if we add the url now you have 20 daps that are pushing back against removing the endpoint so that's my concern with standardizing it yeah we can we can we can add uh a section to it that says discourages use of this endpoint only for temporary purposes or something along those lines the use of this eip um until the new standard comes out uh so essentially it's like a a deprecation warning ahead of time if that makes sense

right um and then we can immediately in there also formulate deprecation of the actual rpc version right i don't can't remember exactly what eip that is it two separate okay so we'd have to make an eip that says this is a notice we are deprecating the rpc endpoint somewhere in the near future and there will be a replacement system incoming i would i would say just convince wallace to remove it like nothing no one is forced to adopt any given standard in fact there are far more standards that are not adopted than there are that are and so it's just a matter of getting wise to stop adopting it and if i may add here that this proposal

is present at present is in the you know pr status right even if it is merged it will be in draft and then it will be in review last call it is not something that we are going to see in less than two months time period so my question will be like one thing the the present proposed proposals that we have in eip repository do we have any consensus on that like if there is anything that can be pursued to be moved as a standard that can help in near future and i know this is like way over the time that we have decided for it so if people want to discuss this further in in next meeting we can probably come up with a date and time that works for everyone and one important question that

we wanted to get solved by this meeting was to have if someone is willing to take kind of you know a lead in that and maybe working with the authors of these proposals to come up with like consensus or which all proposal we can move towards final if there are more than one because i understand with the discussion that it can be based on the use cases not um like individual proposals just so i get to interject here real quick um i'm not here for a one time adding my eip i'm in it for the long game and i am totally down to help out with coming up with that chain list or token list or whatever we end up our pc list

um standard and making it happen and actually getting it implemented in wallets so i think um who decided to schedule this for half an hour what kind of crazy person schedules half hour meetings we didn't know you were coming take it okay um so just to throw a wrench in in this conversation i do actually agree with what matt was saying earlier that right now we have all these you should know by now matt i i know when meetings happen and i just can intuit this and show up

um so there's this issue that right now we have these these l2s and and l1s that all try to look exactly like ethereum so that way they can work with ethereum's wallets and the reason for this is because it's much easier to use ethereum wallets than it is to build your own wallet for your own ecosystem right like no one wants wants to build their own metamask and their own coinbase wallet et cetera et cetera and so they try to make themselves look like ethereum this i suspect this will work up until layer twos start to get actually interesting and i think they are going to start to get interesting sooner rather than later later when i say interesting i mean on these layered twos you're going to want to be able to

do more different things you cannot do in layer one and particularly you can't do an on ethereum and when that happens like this all breaks and so i am with matt that i'm a little hesitant to kind of go down this path of standardizing this behavior of like setting an expectation that you can just plug an rpc into a wallet and it will just work i think that short term that is true and it does i think that in the next five years that will no longer be true and we will have standardized the thing that no one uses because it doesn't make sense anymore because layer one long term is meant to be the settlement layer it's not meant to be adapt player like it's not the hope is is that people will be doing

all their dap stuff elsewhere which means the set of things you might want to do when interacting with your chain is going to be vastly different on the sediment layer versus the top layer right but that's what the the dap scheme is for right i don't think we solve this with this game i think this is a fundamental problem with like long term i don't think you'll be able to have one wallet that was designed for ethereum and use it for solana or arbitram or optimism or stark stark net or whatever i think you'll have to get a wallet that was specifically designed to work with dark net and that might be metamask maybe metamask will support you know

stark net and ethereum and arbitrom but i think they will have to develop for each of them individually and so um i do i just want to be careful that you know we're thinking about the long term here and i think in the long term this whole strategy might not make sense all right so i know we are not going to get a solution right now but at least we get some points to maybe proceed further yeah you definitely gave us food for that so yeah what do people think about having a call in next two weeks is that something reasonable i know you

requested for some time look that you may want to may be able to connect with other wallets if i get it right i don't know i am currently in talks with both metamask and rainbow to get the appropriate changes made and to get um the ethiorl parser updated everywhere to be able to support not only actually running custom functions of smart contracts because currently take metamask for an example only transfer and approve our allowed function names um and you know that needs to change we need to be able to run any function name and any amount of arguments and any

duplicate arguments um so i am definitely involved with the the wallet development and um i have been talking with people at both rainbow and metamask to get these changes uh into the all wallet and i'm assuming that is not specific to 1594 right in general not at the moment no yeah okay currently those changes are upgrading to typescript uh adding a bunch of extra like tests and uh i mean shrinking down bundle size etc etc etc i will drop a pr link in the chat if you want to see it that would be helpful thank you i think maybe we can circle back on the feedbacks that you may have collected

and what other wallets have to say about it what does what do people think about having the same caller two weeks from now at the same time sure i i can make i can make any time all right okay uh then i will i'll try to schedule another one we will definitely share the information in the way we have shared this time on different channels and invite as well so if anyone wants an invite please drop email address to me on discord or anywhere and maybe we will also get back on yeah he's not are you in the discord are you in the wallet discord luke

i am not 100 sure just let me know yeah one second so about max action item talk to wallets about supporting rpc and rpc wallet list is someone willing to talk to or if there is like you know if people want more representative of different wallets in this call i can maybe try getting them on on this call if that's helpful no that's mad i'm just here for the loss

um and i think if there's a little bit more time probably i would like to discuss about erc 4804 if people here are still available for maybe a few minutes i'm fine i mean we can go over 12 minutes if people don't have another call yeah so um this is the another ui standard i recently proposed and also covers with sandwiches and the basic idea is try to uh basically call in the contract and is able to translate the url and put it on

contract and then pass the corresponding data return to the user and one application i'm thinking about is because we are developing l2 with a large storage on top of that so we can use this standard uh to for example uh so we already built a gateway uh so it's not working so it's able to basically upload a whole website or big example the example to query account wsdt on rigby and basically call in the balance of function and then translate the corresponding ns address to the corresponding address of ether and return corresponding value to the 2566 and this

is the result um the reason is that we checked all the ips and haven't found any example standard that is allow us to basically read the state from the ethereum um so basically we created this kind of like a url so that when users want to for example uh locate the resources on the easier kind of like uh basically you uh can't but in web 2 we have dns we have iphs now we have contract we have enos so we are able to translate them and then to be able to locate any resources on top blockchain and then display it uh i think i think this might should work on c dns domains

so this is example that we upload all the ems website on top of encrypt rinkeby and so we user can just type it using kind of like a standard browser uh right now it's using a gateway method and this will basically load all the contract from the uh from the ring b and then display using the web content so this is another application that we would like to basically enable this decentralized website on top of this ethereum yeah so any questions just just had a set of curiosity why not just use ipfs oh yeah that's like it already does all this yeah that's a great question so uh first like um

ipfs that means uh for example it requires for example to clean the data so that means that maybe lost and further if you if i use a want to upload uh for example content it has switched to another platform while in this way so other things is using the uh basically ethereum stack is stored on the ethereum and so we use it doesn't need to worry about whether the website would be shut down but definitely they can also remove the website by distract destroying the contract so from user perspective it doesn't need to understand other techniques that like ipfs filecoin ar it just stick to one platform and do whatever they want and

second is that ffs is more like a static content so people post the content return the hash aware link but in this scenario basically user can interact with basic dynamically create all the content return to the user it's kind of like we are running a web server backed by evm and also the server is by the serum all the nodes in the network uh rather than uh for example we have example reference pointer and point to the ipfs uh static um content but we are not able to modify all this content or dynamic generators content but fix them or we if we want to

compose nft based on different state and yeah we can program what kind of a return data svg then we can append those data dynamic generator svg and then return to the user instead of using static content so the i think the problem you're going to run into is that story and data on ethereum is it's exceedingly expensive and so no one will be able to afford to actually put a website on non-chain yeah yeah that's that's the basically uh the purpose of our sidechain that's doing basically uh because like my understanding that l2 is trying to scale provide scalability what's good is in terms of like a transaction or computation like average

optimism another way is feel like about uh using the ethereum technology we should be also be able to scale the the storage dramatically uh for some time no one is currently working on an l2 the scale storage um i see so you're trying to build an a storage scaling l2 yeah um okay i mean the certainly more power to you i i think the reason no one has worked on it so far is because ipfs does a great job um especially with the introduction of filecoin allowing for permanent storage at paid permanent storage

and so my general recommendation is to figure out how to improve the ipfs integration which is getting better uh all the time like you know i browse all the apps i use i use through ipfs already and it works i would be hesitant to go down a path of trying to replace that um without like i understand the desire of having everything on ethereum um but i don't think you're going to gain enough to be worth the effort like building a storage decentralized storage system is a huge and hard project and ipvs solved it well and so i'd be hesitant to try to replace that

i think there are other things you could replace that would be much more valuable that being said i'm a big fan of people trying new things and exploring and so i definitely i'm not saying you should not do it just be aware you're basically competing against ipfs which is hard not to forget are we even bundler um yeah i think another is ar um but yeah ipfs um i think probably that that i really like that they work in some direction but but like let's imagine let's for example uh we create kind of like dynamic blog uh website that is on top

of the like this technologies uh or versus on ipfs what was the difference there because like i feel like if the user for example when i create a blog i need to go to ipfs i need to click someone maybe pin this or maybe for example to pay a file coin to ping all those storage rather than fixing my or i can be able to fix my post like or retreat just following the smart country logic that are built in into the build on top of evm this is something that i can think about something probably from maybe different uh in terms of application perspective yeah

so i understand this proposal is also not matched yet because i can't find it in the list oh i think it's already merged uh it's just yeah i think it's just it's just i think it was merged last last week 4804 okay i mean i may have missed it i will like to add it here in the list so we have all the proposals in one place okay cool thank you for sharing this we could not reach to the conclusion yet like which direction we would like to move but it's a very good session in which we learned about uh some new proposals solving different problems i

guess we can have another meeting schedule two weeks from now in which we can probably discuss on which all proposals we would like to uh move forward with and if there are authors who are around to may be able to push these proposals would be good if not then someone from whoever joins the call is willing to be a champion for that proposal that would be helpful because as we get into layer 2 solutions more and more it will be useful to have some certain standards and people be following them although i'm not sure if they if one proposal will be able to solve all the use cases but definitely will try to get standard depending upon use cases yeah

i know our light client has dropped off he had to go and the meeting was getting for 30 minutes only so i just to sum up just a reminder if anyone wants to be added on the calendar invite please drop me your email address on discord i'll be happy to add otherwise we'll try to communicate the meeting information in the same any last word from micah before if we conclude for today no i'm like i'm only supposed to be in this meeting right so it's always good right people who are here who are not supposed to be here adding a lot of it but it's helpful and it's important to get different perspectives so thank you for joining and i'm sure this is helpful for all of us

thank you everyone for joining us today hope to see you in two weeks have a good one everyone thank you take care