-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial multi-chain support (aka. optional chainid fix) #4932
Initial multi-chain support (aka. optional chainid fix) #4932
Conversation
55a30bb
to
d7d3ecf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hackmod I think Metamask will avoid adding bunch of providers and chains, instead we need optional chain fix only without ethereum classic support
d7d3ecf
to
470a4c2
Compare
rebased, resolved conflict, changed ETC logo/rpcUrl
now net changes are +675, -172 lines (svg file changes are not counted) |
470a4c2
to
3c3e96c
Compare
@akx20000a
what bunch of providers and chains?? this PR only include ETC chain, no other providers added at all. |
1ad9043
to
9cbb649
Compare
I think its pretty apparent that after 2 years of various networks trying to get integrated into metamask its just not going to happen. Why not just strip the etc stuff from this PR and submit it again with just the optional chain_id for added networks? I know its not as glamorous but it would be nice to move this along. |
hey @hackmod, sorry for the slow response here. @chrisfranko is right - we’re not currently interested in adding Classic to our network menu, as discussed here: https://medium.com/metamask/metamasks-vision-for-multiple-network-support-4ffbee9ec64d We are open to adding support for the Long term, we are interested in ways of supporting different chains without having to impose the politics of a supported network list, but right now, we believe the addition of an extra chain named “Ethereum” would only serve to confuse our already very vulnerable userbase. I hope that makes sense! |
* fixed custom Rpc form to support optional chainid * experimental ETC support added [fixed conflict 8/16]
* etc logo added * price info from https://min-api.cryptocompare.com/
* fixup for testnet faucet
159a695
to
b81c4e3
Compare
* rename frequentRpcList to frequentRpcListDetail to prevent compatible issue
a453eb4
to
50b1e66
Compare
@hackmod Can you please split your PR one for ETC support and one for optional chainid?? Your PR changes price api and lots of stuffs that Metamask will avoid merging this, please split your PR |
@chrisfranko @bdresser @eosclassicteam // OK. Ive made new PR to separate all other stuff except optional chainId. Please see PR #5134 |
closing in favor of #5134 |
from #4516
Description
The customRpc feature support by MetaMask somewhat buggy.
Currently, metamask get the
chainId
usingnet_version
rpc call, butnet_version
does not return the realchainId
. for these cases, we need to know realchainId
to support EIP155 replay protection correctly.more over, In most case of ethereum forks and variants,
chainId != networkId
.This PR has been incubated at #4516 (about two months) and simplified. It is almost minimal fix to support the following.
networkId != chainId
cases.above two features share their code, ETC support is implemented as a predefined customRPC.
that's why I do not separate this fix into two PRs.
net changes are only
+678, -172
linesInfuraProvider()
for ethereum,_configureStandardProvider()
for customRPC are not much configurable.this customRPC implementation is a prof-of-concept quick hack.
not much nice looking but ready to be merged, work nicely and small enough for incremental development.
Done
rpcUrl
+chainId
buyUrl
) (6/23)[x] fixedfrequentRpcList
bug.[x] increasefrequentRpcList
length by 1changelog
References
See also
Screenshot
user configured custom RPCs (upto 3)
example. upto 3 customRpc supported (previously, 2 supported)
(old-ui)