Yea I think their main way of decentralizing is by letting anyone becomes a relay, and the relay is open-source as well. but yea I agree, it does introduce a level of centralization.
Going back to iframe wallet comment, currently in order to do that it doesn’t require a whole new EIP afaik you can simply call parent.ethereum
(I know you are not a fan of this) from the iframe so dapps can simply do something like const provider = window.ethereum || parent.ethereum
and current functionality will be there. Parent window only need to implement the provider interface as a global variable. You achieved a similar functionality in your code as well. However, Iframes have whole another set of problems, starting from ton of vulnerabilities to all the UX/UI issues this is why lot of other projects gave up on it. I remember there was another project who tried to integrate dapps into their wallet interface however, dapps UI doesnt scale properly as no one is expecting it to be inside an iframe also responsiveness goes out the door as soon as you put a website inside an iframe. Security issues are whole another conversation. Due to potential phishing, lot of website also use a header so you cant embed it inside an iframe. Due to all this, I dont think iframe wallet will be a good approach.
That said, I am not against rest of your proposal of using window.postMessage
directly instead of injecting. However, my argument is that we already use it behind the scenes with injected wallets. Your approach client->postMessage->wallet
but the postMessage communication layer needs to be rewritten to handle the issues I mentioned on one of my previous comments.
Current approach client->dedicated variable->postMessage->wallet
This way lets you communicate and make use of existing code base without major changes.
I honestly dont believe best approach for Gnosis to try and host every dapp inside and iframe, it will vastly reduce the user experience and they will run into ton of security issues.
Not sure why it would complicates things when the user wants to sign a transaction? with a proper support to multi wallet standard, they can simply add window.evmprovider.gnosis
variable and handle the communication however they want. Also, we all need to understand, at the end of the day there will be 100s of different wallet types. If you open any of the wallet onboarding libraries (web3onboard, web3modal, web3react) they all have different integrations for wallets. We will never have just one standard that every wallet will follow. Because of this, if you are a wallet provider part of the deal is going after dapps and adding custom integrations and thats unfortunately what lot of wallets including Enkrypt needs to do since there is no proper way of letting dapps know which wallets are available.
Breaking changes are not binary, you have to take into consideration how much work you are expecting the world to do in order to support your change. More popular you are even changing one line of code across every place it is used could be next to impossible. This is why we are stuck with internet protocols that were invented in 3-4 decades ago. Changes proposed by this EIP is easier to adopt than the changes you are proposing. At the same time, your proposed changes doesnt provide any significant advantages. We can come up with an extremely complex model that could be applied to every blockchain out there, however it doesn’t mean people will adopt it and we will still have issues around window.ethereum
for the foreseeable future.
I am consfused about this, wdym by “IPFS hosted web wallets” also I am not sure whether wallet could be fully decentralized. Blockchain data is not in ipfs so the wallet needs to connect to a centralized node at some point to get the data and broadcast tx.
I dont think this could be done with current technology, how is the wallet getting blockchain data? it still needs to interact with a node. Only way this could work without a node, if the user willing to manually set the gasprices, nonce and willing to take the signed tx and broadcast it somewhere else or user needs to have a node running or access to rpc address. This is a very specific use case and not sure how many users are technical enough to even achieve this.
Yea but like I mentioned before all breaking changes are not the same, if we can make a change that can solve a problem with least amount of work I believe that will get adopted rather than a massive change. Otherwise users will be the ones who’ll suffer forever. Also dont forget the fact that, each new line of code can introduce a vulnerability that we didn’t think about, injection method has been battle tested for 7+ years.
I think best cause of action for your proposal is to make it an EIP and have a separate discussion around it. I will be more than happy to participate and give you my thoughts around the extra communication layer we need, I can also make Enkrypt team implement it if it is satisfactory. There is no reason for a wallet to only support one standard.