EIP 1193: Ethereum Provider JavaScript API


#21

That sounds like a good idea. After finishing our implementation in Mist, I will see if I can propose eth_changeNetwork as an addition to the RPC specification. Thanks again for your help.


#22

I would also say that account change etc should be future subscriptions. The reason why I introduced the new subscription model back then was to allow many new subscription types like: account changed, state changed, balance changed, etc. to be implemented and added in the future.
This would require no change to the basic subscription ali proposed here, just anew type with or without extra Params.

On the other hand the unsubscribe should also work for “networkChanged” and such. This is currently not specified.
@ryanio you proposal also says it should implement the sendAsync method to be backwards compatible. I would not do that, as the web3 provider used since 2 years has send function being a sync, I would rather let libraries like web3.js deal with handling the different provider types like legacy web3.currentProvider


#23

I like the idea. I am a fan of as thin as a provider as possible, so having those events as subscriptions sounds smart.

How would we go about implementing the new subscription types though, would we need to propose them to the node teams (geth, parity, etc.) to implement? The way it is currently set up, it is much easier for the provider clients (Mist/MetaMask/Status/etc.) to implement and emit when the user changes which accounts are authenticated to the dapp or when the user changes the network.

Right now those events are specified to be emitted using EventEmitter so you would just use window.ethereum.removeAllListeners('networkChanged').

The subscribe/unsubscribe methods as currently defined are meant to explicitly be used for the pub-sub spec.

Ok sounds good, I would much prefer not needing to provide methods to make it compatible. Is there someone on the web3.js team I can get in contact with to help enable the provider as defined in this sample implementation to work as a web3.js provider?

I had to provide sendAsync to get it working as expected, but if we could handle it inside web3.js itself that would be great. I think the lib would need to recognize the EthereumProvider object and use send and then manage the callbacks itself inside the lib’s request manager. At least that’s my understanding of what you meant, let me know if I’m interpreting it incorrectly.

Thanks Fabian!


#24

I’m using Typescript syntax since it’s straightforward to test.

ethereum.send(method: String, params?: Array<any>): Promise<any>;

Why not also return the response ID?


ethereum.subscribe(subscriptionType: String, params?: Array<any>): Promise<String|Error>;

Javascript Promises already reject with Error that is caught using .catch(). There’s no need for an Error return type on top of that.

ethereum.subscribe(subscriptionType: string, params?: any[]): Promise<string>;

ethereum.unsubscribe(subscriptionId: String): Promise<Boolean|Error>;

Same reasoning as above.

ethereum.unsubscribe(subscriptionId: string): Promise<boolean>;

ethereum.on('accountsChanged', listener: (accounts: Array<String>) => void): this;

I think the casing of the account addresses needs to be specified. What about considering this alternative?

ethereum.on('account.added', listener: (account: string) => void)
ethereum.on('account.removed', listener: (account: string) => void)

#25

Is there any benefit to have it?

(What would you do with it? How would you want it returned?)

Great point, I’ll update.

I’m not sure, I think it adds more complexity. I’m thinking dapps should be smart enough to react on the accountsChanged array of addresses. Having an event per account doesn’t make much sense if the user adds or removes multiple accounts at once, just creates more handling logic rather than the dapp reevaluating its state on accountsChanged. What do you think?

Thx!