search

fxfactorial / ethereum-re

Access the ethereum network with pure ReasonML, use with native code or with type safe JavaScript
20 stars 1 forks source link

web3.js compatibility ? #1

Open rsaccon opened 6 years ago

rsaccon commented 6 years ago

Will the JS version expose a web3.js compatible object, so it will work with metamask ? Or is this lib rather meant to directly access local (or remotely) running ethereum nodes ?

fxfactorial commented 6 years ago

Great question. Compatibility with web3js isn’t s priority but I could definitely add a few compatibility layer functions. What objects you want exposed and how do you want them structured ? What things metamask wants ?

rsaccon commented 6 years ago

I just started to tap into ethereum and right now I am only using web3.utils.sha (seems that is the thing where you also started with your lib, at least at the JS side). I will take a closer look at metamask the next days to try to find out what metamask wants. Wouldn't it make most sense to structure exposed objects the same way web3.js is structured ? See http://web3js.readthedocs.io/en/1.0/web3.html. For my particular use case, I am interested in SWARM, that has its own http REST interface, but for things related to ENS and accounts there is RPC access to ethereum node needed. I am also interested in pss (there is a JS example) however last time I checked, that kind of stuff only worked (well, didn't really work for me) with geth from master. I think web3js is an unnecessary layer of bloat, if we access ethereum from reasonml JS, so I hope to get rid of it, and I think this project will help to get there !

fxfactorial commented 6 years ago

Yea exactly! I initially started writing bindings to web3 with bucklescript but actually I don't much like that code.

We can definitely have a web3 compatibility module for the web portion so that we can interopt with web3 easily.

rsaccon commented 6 years ago

I started to dig into the metamask sources and docs and I am just writing down my findings (before I forget them). Got scared by the HUGE amount of things involved. Anyway, according to this guide, metamask intercepts / proxies sign and sendTransaction calls, if a webapp has its own web3 object defined. Internally they use this minimal web3-alike for the actual RPC calls. So my current wishful thinking is: JS ethereum-re just needs to export web3.eth.sign and web3.eth.sendTransaction and metamask can do at least its most important thing as it would when a original web3 lib is present.

Another thing is account management, here I am just guessing, ethereum-re should export web3.eth.accounts as empty array, and then just regularly poll it, to check whether netmask has defined or changed it.

fxfactorial commented 6 years ago

When you say export web3.eth.sign, do you mean export a bucklescript function that is a binding to that actual object's from the web3js library or do you mean writing a small object that have the structure of a .eth.sign function which then runs our own implementation of fetching & working the JSONRPC.

rsaccon commented 6 years ago

the second, so metamask can overwrite it with its own implementation. At least this is my current understanding of how this things play together. Of course I do not want an actual web3.js in my app!

fxfactorial commented 6 years ago

whew! Was hoping you'd say that.

Okay so let's list out what exactly the compatibility object needs to expose