Explore what needs to be done to expose ETH RPC

[massa-bot]

In GitLab by @damip

Do research on the list of things we need to add/change to expose an ethereum RPC interface (https://ethereum.org/en/developers/docs/apis/json-rpc/) additionnally to the current api

Prioritize the parts necessary to make metamask be able to communicate with a local massa node https://metamask.io/

[massa-bot]

In GitLab by @gterzian

@damip Could you document the goals of this more please? I assume the API is quite large, and we only want a subset of it.

Prioritize the parts necessary to make metamask be able to communicate with a local massa node

Here do you mean "communicate" as in, "can handle the RPC", or as in "can provide some specific useful API response". Maybe those two things can also be discussed separately, since the network communication part is a different problem from the "what part of the API we want to support" one.

[massa-bot]

In GitLab by @damip

@g-massa it boils down to "what needs to be done so that people can use metamask with massa"

[massa-bot]

In GitLab by @yvan-sraka

Previous issues related to API refactoring:

• https://gitlab.com/massalabs/massa/-/issues/48
• https://gitlab.com/massalabs/massa/-/issues/53
• https://gitlab.com/massalabs/massa/-/issues/64

[massa-bot]

In GitLab by @yvan-sraka

Useful links:

Metamask.io

• all methods: https://docs.metamask.io/guide/rpc-api.html#ethereum-json-rpc-methods
• important methods: https://metamask.github.io/api-playground/api-documentation/

Ethereum JSON RPC

• wiki: https://eth.wiki/json-rpc/API
• playground: https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/eth1.0-apis/assembled-spec/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=true&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false

[massa-bot]

In GitLab by @yvan-sraka

mentioned in merge request !170

[massa-bot]

In GitLab by @yvan-sraka

created merge request !170 to address this issue

[massa-bot]

In GitLab by @gterzian

Right.

So I think what needs to be defined, perhaps after some initial research, is the term "can use".

After some initial research it seems to me that:

1. If we implement an RPC layer that supports this API, it should be compatible with Metamask.
2. This still leaves the question of how much of this API we want/can support. For example I see one endpoint that takes a "number", and returns a block, which doesn't seem compatible with our concepts of thread. There's another endpoint that exposes the "hash rate", which again doesn't seem applicable. Question is a. what do we want to support, and b. can we suppport only part of the API and still be compatible with Metamask.
   I have opened an MR with a .MD doc and discuss all the methods one by one to determine what we want/can support?
3. Thirdly, as described in this blog post, the current experience of connecting over RPC to another network(in this case Massa), still leaves a lot to be desired, while there are some ongoing developments to improve on this. What do we want to aim for?
4. Do we want to implement a web site that users could go to using Metamask, and that would hide all the RPC stuff and provide a UI?
5. There seems to have been some relevant discussed here, although it's not clear to me what the outcome was...

cc @ALL

[massa-bot]

In GitLab by @yvan-sraka

mentioned in merge request !172

[massa-bot]

In GitLab by @yvan-sraka

Further design discussions are centralized here: https://gitlab.com/massalabs/massa/-/merge_requests/172

[massa-bot]

In GitLab by @yvan-sraka

Since we closed https://gitlab.com/massalabs/massa/-/merge_requests/172 do we close this linked issue too?