Update EIP 1193

[rekmarks]

Link to file: https://github.com/rekmarks/EIPs/blob/rekmarks-1193-update/EIPS/eip-1193.md

Makes the following updates to EIP 1193, in light of recent discussions in #2319:

• Deprecates send and sendAsync
  • Providers may continue to support these methods
• Specifies a new method, request, with the same Promise signature as the send currently at ethereum/EIPs#master
  • Per @MicahZoltu's suggestion
• Changes the interface of the notification event, such that a generalized object is emitted
  • This was done to support other notifications than eth_subscription
• Makes the spec transport- and RPC protocol-agnostic, per the contributions of @ryanio
• Adds the message event for generalized messaging, and deprecates the notification event
  • This is so that existing uses of the notification event do not break
  • All functionality previously handled by the notification event is now handled by the message event
• Various edits for clarity and stylistic consistency

[axic]

cc @alcuadrado @ryanio

[adrianmcli]

At first read, only one thing stood out to me! Great work @rekmarks!

[rekmarks]

cc: @ricmoo @MicahZoltu @danfinlay

I am in touch with @ryanio

[davidmurdoch]

Since this renames send to request do we not need to consider versioning this API now?

[danfinlay]

Since this renames send to request do we not need to consider versioning this API now?

Since this is not in production anywhere yet, and is in DRAFT status, I don't think we need to version.

I sometimes fall on the other end of the spectrum: I somewhat wish proposals were hash-locked, because some specs evolve after they've gone to production (see EIP 712: eth_signTypedData).

I also don't think a version number always does justice to the evolution of a spec, since two versions could conflict and not build on each other.

But since this is both DRAFT and not in production anywhere, I think it's okay to eschew versioning for this iteration. Let me know if there's a reason to disagree.

[davidmurdoch]

@danfinlay, previously, a versioning mechanism was being discussed because the signature of send was changing. MetaMask already injects send onto window.ethereum, for example, so we were trying to figure out how dapp developers could differentiate. Now, with this function being renamed, it seems we don't have to. ♥️

[adrianmcli]

@rekmarks how come the chainId was changed from a number to a hex string? Do we envision trillions of chains? 😂Just curious.

[MicahZoltu]

I think versioning or capability detection (or versioned capabilities!) is still an incredibly wise thing to do, but I agree that can and probably should be a separate EIP from this one. Ideally that separate EIP would be done first, and this one would follow it (adding a new capability/version) but I understand that beggars can't be choosers.

[rekmarks]

@adrianmcli I suppose we are! See: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-695.md

Relevant excerpt:

Returns

QUANTITY - integer of the current chain ID.
...

References

Return value QUANTITY adheres to standard JSON RPC hex value encoding, as documented here: https://github.com/ethereum/wiki/wiki/JSON-RPC#hex-value-encoding.

Geth, Parity, and MetaMask are already returning hex strings for chainId. I see no benefit to making it a number; only costs. (Planting my flag here.)

[frozeman]

I personally find the examples in JS better :) and a bit to much text.

But the ideas are great and giving a notification type makes a lot of sense!

Great job @rekmarks

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1193 requires approval from one of (@MaiaVictor, @frozeman, @marcgarreau, @ryanio)

[rekmarks]

My thanks to all of you for your feedback!

As far as I'm concerned, this is ready to be merged.

[ryanio]

LGTM, thanks for all your work on this!