search

polkadot-js / extension

Simple browser extension for managing Polkadot and Substrate network accounts in a browser. Allows the signing of extrinsics using these accounts. Also provides a simple interface for compliant extensions for dapps.
Apache License 2.0
977 stars 416 forks source link

Add network bounds / is hardware to accounts.subscribe callback #1192

Open rossbulat opened 1 year ago

rossbulat commented 1 year ago

There is a limitation with hardware-wallet imported accounts that's not only subject to Polkadot JS extension, but to the injectedWeb3 accounts subscribe spec being used.

Ledger devices sandbox accounts to 1 network, and will therefore only work for that 1 network. The issue is that the network(s) an address is "bound to" are not communicated in the injectedWeb3 accounts.subscribe API. When I subscribe to the accounts of the extension, apps need to know the supported networks in order to display or ignore the account correctly, depending on the active network within the app.

Proposed solution would be to include optional hardware?: ledger_nano_s | <other> to signify account is from a hardware wallet, and networks?: Array<string> properties within the returned account list that returns a list of networks supported by the address. Perhaps the names adhere to the same spec as Ledger Substrate JS.

This would also be useful if we wanted to roll out Ledger support on only one network - say Polkadot, whereby the Polkadot-only accounts only use the Polkadot Ledger app & accounts will only be displayed when on that network.

A practical use case: The Polkadot Ledger app just rolled out nesting support for all the staking functions used in staking dashboard. Kusama does not support such yet - we need to therefore silo Polkadot hw support from Kusama hw support.

jacogr commented 1 year ago

Generally the focus is on web3Accounts and web3AccountsSubscribe and it is the recommended approach to retrieve as opposed to the lower-level per-extension .subscribe which is actually not controlled in the web3* interfaces. (These are provided by all extensions themselves so it is a really low-level interface)

Both these web3* methods do allow the filtering capabilities, e.g. on genesisHash as per the options passed

https://github.com/polkadot-js/extension/blob/7b5da604454afbc15b36e679afedd443c14735aa/packages/extension-dapp/src/bundle.ts#L137

https://github.com/polkadot-js/extension/blob/7b5da604454afbc15b36e679afedd443c14735aa/packages/extension-dapp/src/bundle.ts#L171

I agree it could be useful to somehow roll this out to eg. lower-level subscribe as well, however that obviously has some thinking required for backwards compatibility. (And obviously if different extensions implement their own subscribe, aka it is not polyfilled like we do for those that don't in web3Enable, it would actually be be quite a hit-and miss exercise.)

So maybe for the future if we can find some workarounds for the various incarnations.

rossbulat commented 1 year ago

Thank you, this is useful. The issue I faced with web3Enable (separate to the above) is that it summons all available extension pop-ups; this has prevented me from using it. Would an additional optional argument to the function allowing us to give IDs to a particular extension(s) to enable be too much of a stretch to add? Or an additional web3EnableById function so the existing ones are not touched?