Putting this first (out of order from your message) since I think the rest of the discussion is largely not relevant as long as we disagree on this point.
While you are correct that a tiny change is easier to get adopted than a large one, I think this is lost in the noise to the overall cost of an ecosystem wide breaking change. If we assign arbitrary units, getting the entire ecosystem to adopt any breaking change (e.g., epsilon sized) is say 1000 units of effort and a one line change is +1 units of effort and a big change like switching to window.postMessage
is +10 units of work. Yes, it is 10x harder, but it is still insignificant compared to the cost of doing any change.
Your mentioning of decades old protocols I feel helps my argument here because it exemplifies just how amazingly hard it is to do any change. IPv6 is arguably one of the smallest possible breaking changes to a core internet protocol, just changing the size of a number essentially, yet it has taken ~25 years to get adopted and it still hasn’t supplanted IPv4. I really think we need to get this right rather than doing the smallest thing possible because it may take us years to get broad adoption of anything, and that thing should be provide the maximum utility as we may not get another chance to do a breaking change (the more Ethereum grows, the harder it will be).
Due to firewalls, this generally doesn’t work because users don’t run servers that can accept incoming HTTP connections. I have heard that there is a way to get two devices on the same internal network communicating (thus potentially avoiding NAT issues), but I’m not sure how realistic this is.
I would like more details on the downsides to iframe wallets you see. I have implemented one, and Gnosis has implemented one, and I haven’t run into any of the problems you mentioned here. The only problem we have both run into is the fact that dapps require an injected provider and so don’t work by default (you need an extension to do the injecting, or you need the dapp to support another mechanism of connecting to the host wallet).
What are the fishing vectors you see here?
What are the security vulnerabilities?
What are the performance problems?
For the UI issues I think perhaps you are imagining a visual iframe with the host all around it and it has its own scrollbars and whatnot? I’m envisioning something more like the host page just has a little toolbar on the top or bottom, or perhaps a floating tab on one of the sides but the app’s iframe is basically the entire window. In the one I wrote, it was a floating header bar that could be collapsed down to just a tab that you could click to bring it back, but the dapp got essentially 100% of the viewport to itself. Gnosis does have left and top bars, and I haven’t noticed any problems with it but perhaps I just haven’t used enough dapps to run into trouble?
This one is quite unfortunate, and frustrates me quite a bit. I don’t think dapps should be doing this (I am not convinced it offers meaningful protection for a dapp), but you are correct that some do it none the less.
I’m not sure which comment you are referring to specifically, but I believe I have already replied and mentioned that these things were already solved in my prototype SDK? I would be happy to discuss more, but I feel like it is out of scope of this specific discussion beyond just saying that it is a very solvable problem and one I believe is in fact already solved in my prototype (so not just theoretically solvable).
They literally cannot do this. This is exactly the problem I’m trying to describe. An iframe host cannot inject into or mutate the hosted iframe. This is a core browser security/sandbox thing that is very unlikely to go away. They cannot provide any variables to the dapp they have in an iframe. The only way they can communicate with the iframe dapp is via window.postMessage
.
Meaning iframe host wallets like Gnosis, which can be hosted on IPFS (unlike a browser extension, which cannot be).
Users should be running their own node or using an embedded light client, but that is a separate problem that I am advocating for elsewhere.
The iframe host wallet behaves the same as an extension wallet. It would allow the user to set a JSON-RPC provider, or it would have an embedded light client, or it would provide a centralized RPC for the user.