We have a bit of a UX nightmare for proxies whereby we cannot determine whether an account is a delegate without also having knowledge of the delegator. This prevents applications to automatically determine a delegate & prevents it from behaving as such.
This IMO is a severe limitation that will hinder proxy adoption throughout the ecosystem.
I have outlined the rationale of the proposed solution, as well as the work-arounds currently being undertaken for the staking dashboard, in the following Substrate issue:
Posting here for discussion / if there are any major pushbacks in doing this.
Given our discussion is getting a bit out of topic in the context of Substrate repo, I will continue the discussion here instead.
So a large part of my work currently is to move away from web extensions and support hardware natively and directly. This is an optimal experience and dramatically reduces the learning curve of having to add, set up and manage web extensions (across browsers). Not only this, we are no longer limited to the web browser when web extensions are omitted in favour of hardware wallets.
I can see why this could be useful. The less software, the easier for user to onboard. However…
In response to this I strongly suggest that we do not rely on a future where web extensions or middleware wallets are solely responsible for managing hardware or even facilitating features like proxy. Apps should have this capability to ensure direct communication with hardware wallets is possible.
I don’t agree with this. I trust extension/wallet more than a dApp. The WWW is built with the assumption that the websites are not trustworthy. This is why browsers sandboxed the execution. I don’t know the if the website is still the same website after a refresh. While extensions can also self-update, it is generally harder to hijack an extension than a website.
As a result, I want to see the dApp does what the dApp do. Handle the business logics. I do not want the dApp to manage my proxy and multisig accounts. I may not want it know this account is a proxy account for whatever reason.
Another example, I want my wallet have a contact list of known address. I do not want any dApp to access all the contact list for obvious reason. Those features can only be implemented in the extension/wallet and they are critical for security (user may want to enable a flag to never allow unknown address to appear in the signing data). I just cannot see how it is possible to eliminate the middleware.
This does not make sense to me, web extensions follow the same rules & sandbox within the browser environment as apps do, there is little differentiation in terms of security implications between the 2.
I think sensitive data like contact lists is outside the scope of this. Apps should primarily use publicly accessible chain data by default & offer opt-in plugins (centralised APIs) if users choose to use them. Beyond this I do not see security implications.
Web extensions will continue to be useful for those who do not have hardware wallets - or those who simply want to use them. But there is a simpler alternative approach of direct hardware support, which should not be sacrificed for the purpose of forming an ideology of extensions & wallets having to do some task instead of an app. We should be guided by the best user experience first and foremost.
We are getting a bit far from this reverse lookup proxy debate though
web extensions follow the same rules & sandbox within the browser environment as apps do, there is little differentiation in terms of security implications between the 2.
Extension releases are controlled by extension store, which does have some effort to prevent abuse (effectiveness is another topic). Website are managed by website owner, and it is relatively easy to hijack a webpage.
We are getting a bit far from this reverse lookup proxy debate though
Yeah…
Anyway, I don’t support this because I think this adds runtime overhead and does not improve security. It does improve UX.
I also don’t against this if we cannot find a better solution. The runtime overhead is relatively small and not a dealbreaker.
The data that we are looking for is essentially onchain, this is mainly a matter of indexing. It is perfectly fine for you to query a centralized API for proxy -> delegate and then re-verify it with the onchain delegate -> proxy mapping that already exists.
One counter argument is that proxies are a huge game changer and if we unleash their UX, it could benefit Polkadot immensely. I have nothing against that, but I am not convinced that the key to that unleash is a reverse map onchain.
Even if we start to make such reverse maps for UX sake, it will be slippery slope where all use-cases will then need more data-onchain (e.g. how many ppl have asked for a user -> assets map?)
We briefly discussed some kind of a secondary database kept by the clients that you can query similar to to state, which is essentially for such indexing use cases. Optional, and nothing that we draw consensus upon. Sounds interesting, and is more resilient but the data that the client keeps, from the security or trust perspective is no different than a data that an indexer stores.
TLDR; I see it unlikely that we will move to this direction.
I agree that this sort of ‘convenience’ data doesn’t belong on-chain and is best indexed and queried using a secondary database. Preferably the indexer should be open source and permissionless to run so anyone can spin up one up alongside their node.
For the immediate proxy use case @ross, I remember we discussed using the Subscan API in our call but if that happens to not be powerful enough I suggest looking into Subsquid which I’m sure will support this use case.
