EIP-5749: The 'window.evmproviders' object

[SamWilsn]

@kdenhartog

unlikely to support any feature requests that are driven by web3 use cases

What about people who have gmail and outlook email accounts? I’m sure they’d love this feature

@kdenhartog

I’d be a -1 to holding a change like this up until we get support for specific features in the browser.

I would generally agree, but not in this case. We can use scheme handlers today and get a significant improvement on functionality over window.ethereum. If/when chrome adds the chooser, users get the benefit for free, no dapp or wallet changes required.

@kdenhartog

I’d be a +1 to setting the requirement that this solution MUST support non-evm based chains. That probably also means we’ll need to consider a venue other than EIPs to standardize this so that we can bring other large wallets to the table.

We can use the EIPs process to set precedent for other chains to follow. For example, with the scheme handler approach, wallets can register handlers for bitcoin://, ethereum://, solana://, etc. and the actual message structures can be defined independently for each chain.

[kdenhartog]

@SamWilsn

What about people who have gmail and outlook email accounts? I’m sure they’d love this feature

Yeah that seems like a reasonable way to push this feature through. Just wouldn’t suggest mentioning anything web3 related was my only point.

@SamWilsn

I would generally agree, but not in this case. We can use scheme handlers today and get a significant improvement on functionality over window.ethereum. If/when chrome adds the chooser, users get the benefit for free, no dapp or wallet changes required.

From what I’m seeing on Navigator: registerProtocolHandler() method - Web APIs | MDN Chrome does support this, but I’ve not actually tried to implement with this. Do they just not support the web+<string> support or something? Given this support I’d withdraw the original -1 since this seems like a promising feature to build on.

We can use the EIPs process to set precedent for other chains to follow. For example, with the scheme handler approach, wallets can register handlers for bitcoin:// , ethereum:// , solana:// , etc. and the actual message structures can be defined independently for each chain.

Yeah this is likely the biggest tradeoff here is what’s the proper way to handle registration and coordination of the schemes. I think there’s probably some considerations that need to be made around this, but nows probably a bit early hash these out.

Let me play around with this approach a bit more and try and get some implementation experience with this approach so I can better understand the tradeoffs here.

Thanks for sharing!

[SamWilsn]

@kdenhartog

From what I’m seeing on Navigator.registerProtocolHandler() - Web APIs | MDN Chrome does support this, but I’ve not actually tried to implement with this.

I’ve tested it in Chrome here.

[sbacha]

Has anyone tested this with Safari? demographically speaking Safari has the best penetration with 18-29 year olds (arguably web3 target demo). Also Safari has redone their extensions framework for their browser, you can convert chrome extensions to be safari compatible (YMMV ofc).

Last question, why usage of UUIDv4? Why not use browser extension id? There are numerous insecure UUID implementations out there, is that a concern?

Should this also respect CSP Policies / have a required CSP setting for websites to be able to interact with this or is that beyond the scope?

Thanks