search

MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
11.86k stars 4.84k forks source link

Add Web3 1.0 support #2350

Closed danfinlay closed 6 years ago

danfinlay commented 6 years ago

Appears to include:

kumavis commented 6 years ago

or just polyfill subscriptions also: we're already no longer using provider-engine! : )

GrandSchtroumpf commented 6 years ago

Is it normal if I cannot find MetaMask provider with Web3 1.0 ? When I check on Web3.givenProvider || Web3.currentProvider, I always got "null", even after several seconds...

danfinlay commented 6 years ago

Not capitalized. Just web3.currentProvider

GrandSchtroumpf commented 6 years ago

Ok, I tried, it works, thanks. It tooks 500ms to find. Just for you to know, here is what we can read on Web3 1.0 documentation : "After that you need to create a web3 instance and set a provider. Ethereum supported Browsers like Mist or MetaMask will have a ethereumProvideror web3.currentProvider available, web3.js is setting this one to Web3.givenProvider. If this property is null you need to connect to a remote/local node."

Which is wrong because I can find web3.currentProvider, while Web3.givenProvider is null.

danfinlay commented 6 years ago

Since the Web3 class is the one you're importing from web3 1.0, I think they're instructing you how to assign the provider to their object. They're not telling you what to check. If this was confusing to you, you should open an issue on their documentation.

GrandSchtroumpf commented 6 years ago

Hmmm, indeed it makes sense. Maybe my English is guilty here, but if I misunderstood, maybe other will. Thanks anyway, it makes my life much more simple.

GrandSchtroumpf commented 6 years ago

Any idea when "web3.eth.subscribe" will be available with MetaMask ?

gitcoinbot commented 6 years ago

This issue now has a funding of 0.3 ETH (241.43 USD) attached to it.

ecp4224 commented 6 years ago

If no one is currently working on this issue, I'd like to tackle it.

What's the best way to start this? Is there a gitter or something similar to discuss details?

owocki commented 6 years ago

@edkek you can use the github issue page :) or https://gitter.im/MetaMask/Lobby

kumavis commented 6 years ago

here is my roadmap for this feature:

i'd like to separate the notions of websocket transport and subscription support. I think it should be easy enough to provide subscription support on top of http rpc (which will Infura's life easier) with the help of eth-block-tracker.

awgneo commented 6 years ago

Will Infura be content with the many polling calls introduced by eth-block-tracker?

kumavis commented 6 years ago

@awgneo we already use the block-tracker, it effectively reduces the number of requests made by a dapp via per-block client side caching

gitcoinbot commented 6 years ago

The funding of 0.3 ETH (221.33 USD) attached has been claimed by @muhammaddava1321.

@muhammaddava1321, please leave a comment to let the funder (@owocki) and the other parties involved your implementation plan. If you don't leave a comment, the funder may expire your claim at their discretion.

owocki commented 6 years ago

@muhammaddava1321 please introduce yourself

owocki commented 6 years ago

@muhammaddava1321 if i dont hear from you soon, im going to reject your claim and let someone else take this. nothing personal, just want to make sure someone who's making coordinating with everyone a priority has the claim. let us know!

owocki commented 6 years ago

i am rejecting this claim due to radio silence from the claimee

choochootrain commented 6 years ago

@owocki i'd like to claim this! i'll start poking around and get a preliminary changeset out

owocki commented 6 years ago

@choochootrain can you please submit a claim on https://gitcoin.co/funding/details?url=https://github.com/MetaMask/metamask-extension/issues/2350 ? thats the source of truth for who has it claimed :)

gitcoinbot commented 6 years ago

The funding of 0.3 ETH (221.28 USD) attached has been claimed by @choochootrain.

@choochootrain, please leave a comment to let the funder (@owocki) and the other parties involved your implementation plan. If you don't leave a comment, the funder may expire your claim at their discretion.

choochootrain commented 6 years ago

here's my mental model of this so far: i have to read up on the new web3 surface area and work backwards to see what changes need to be made to the metamask provider (this is json-rpc-engine with the eth-json middleware?), which uses eth-block-tracker under the hood. @kumavis is this accurate?

i'll dig into this further on monday - happy new year!

owocki commented 6 years ago

@choochootrain ill let the metamask folks comment on the scope... (but they might be busy catching up from the holidays)

looking forward to seeing this done :)

kumavis commented 6 years ago

@choochootrain yep. see my roadmap for this feature above: https://github.com/MetaMask/metamask-extension/issues/2350#issuecomment-353437246

benjamincburns commented 6 years ago

I've been working on websocket, pub/sub, and web3 1.0 support for ganache-core over on trufflesuite/ganache-core#14 (though don't look too closely yet, as the PR does not yet include my WIP changes which are fairly subsantial).

We use the provider engine in ganache-core, so my work has kind of bumped up against this issue, as well as MetaMask/provider-engine#189. Here's what I've done so far in the context of @kumavis' roadmap above.

Apart from the above, I've also modified heavily classes called WebSocketServer and ConnectionManager from the PR which I linked above. The latter type is meant to handle routing of subscription notifications to the correct WebSocket connection, and clean up subscriptions when websocket connections close.

HTH.

kumavis commented 6 years ago

add a matching api to https://github.com/MetaMask/eth-json-rpc-middleware/blob/master/providerFromEngine.js

this part is easy (here's a PR), but requires

add a server-push interface to json-rpc-engine

to wire it up

kumavis commented 6 years ago

I think create a eth-json-rpc-middleware that implements the subscriptions should be pretty easy, but will check in with @benjamincburns tomorrow on that specific part

benjamincburns commented 6 years ago

Managed to get the SubscriptionSubprovider working today with only minor changes to the FilterSubprovider. Will clean it up in the morning and submit a PR.

benjamincburns commented 6 years ago

I've raised MetaMask/provider-engine#207 for the SubscriptionSubprovider work mentioned above.

choochootrain commented 6 years ago

@benjamincburns it looks like you have a good handle on what needs to be done :)

it looks like tackling the json-rpc-enginee and related work is where i'll start tomorrow.

choochootrain commented 6 years ago

didnt get a chance to get to this today unfortunately - if anyone wants to take this on feel free, otherwise ill hopefully get time this weekend

benjamincburns commented 6 years ago

@choochootrain & others on this thread - I work for ConsenSys, so to the best of my knowledge, I'm not eligible for this bounty. My main reason for doing the work that I've done is to get trufflesuite/ganache-cli#257 finished, which is blocked on some, but not all, of the items in @kumavis' list above. We use the web3-provider-engine, not json-rpc-engine, so any work I'd do there wouldn't be in service of my goal.

I'm posting here because the work I'm doing is very analogous to the work that'll need to be done for MetaMask. I figured people trying for the bounty here might benefit from seeing how I'm accomplishing this task in a similarly structured project.

Speaking of which, have a look at websockets-pr-redux over on trufflesuite/ganache-core and compare it to the develop branch if you'd like to see my work thus far.

benjamincburns commented 6 years ago

My WIP for ganache and friends is over at trufflesuite/ganache-core#49, should anyone want to use it as an example. Explanation as to how it all works is in the description.

vs77bb commented 6 years ago

@choochootrain Howdy, I just joined Gitcoin alongside @owocki. Checking in to see your progress here? Happy new year everyone!

choochootrain commented 6 years ago

hey @vs77bb :wave:

i'm way more swamped that i expected right now so the earliest i can get to this is next week..if anyone wants to take this on in the meantime feel free!

owocki commented 6 years ago

@choochootrain if it's okay with you i will reject your claim and let someone else take this

choochootrain commented 6 years ago

:+1: go for it @owocki

owocki commented 6 years ago

ok i've rejected the claim so that someone else can pick it up! @vs77bb

vs77bb commented 6 years ago

@owocki If I recall correctly, @danfinlay said this one is near completion with work from @benjamincburns!

owocki commented 6 years ago

@benjamincburns

we talked internally about you taking on this bounty... basically the question boiled down to: 'is it ethical for consensys team members to compete w. the general public for the bounty? does it fit within the mission to push open source forward'.

i think the answer we decided on internally was that probably no for the first question, but yes for the second question.

in the spirit of being fair to the community and accomplishing our goals as a development community, we then talked internally and we like the idea of taking the ETH you would have earned on this metamask bounty and staking it on some truffle related issue after that .. thereby paying it forward to allow the gitcoin community to work on some truffle issues

id be curious if @kumavis and @danfinlay would be into that.. does that sound like a good middle path to the group?

danfinlay commented 6 years ago

I was just thinking about this yesterday!

Therefore, we need to be able to work on issues with bounties, and yeah, this creates potential for unfairness, so we have to seek that middle path, as you've said.

Anyways, I think we've done a good job here so far. Ben was very transparent about working on this, and then you've formally dropped the claim to open it for someone else, so looking good!

benjamincburns commented 6 years ago

Just to be clear to anyone reading along, at time of writing this bounty is still very much open and eligible for the community to scoop up.

I just want to clarify that I was under no expectation of receiving a bounty for this. I pinged @owocki yesterday just to ask what the official rules are.

While I agree that me being eligible to receive the bounty in this case would cross some ethical lines, I don't necessarily agree that ConsenSys members being paid out bounties is always double dipping. For example, it's shaping up to be an abysmal and rainy weekend, and I could see myself hacking on some bountied bugs for (edit: profitable) fun. I'd hope that so long as I steer clear of ConsenSys projects I'd wouldn't be ineligible just because GitCoin is facilitating.

That said, I'm saying all of this publicly because I want to make sure I'm doing the right thing, so I encourage others to disagree with my position on this, so long as they help me out by teaching me where I've gone wrong.

If we regularly closed our own bounties out from under external contributors, we would create an environment that's frustrating to contribute to, so we need to be incredibly transparent about when we're working on a bountied issue. This could be both with formal assignee/bounty claiming, or also with less formal "general protocols", like "we will always work on our highest priority issues first."

I share this concern as well, and I'd think that in cases where we intend to complete our own bountied issues, we should be participating in the claiming process, or delisting the bounty. It's tricky, because we're likely to align bounties with the highest priority issues, meaning we're probably likely to work on them in relatively short order if the community doesn't pick them up.

we like the idea of taking the ETH you would have earned on this metamask bounty and staking it on some truffle related issue after that

@danfinlay - I could be mistaken, but I didn't see you weigh in on this... what was your opinion on the above?

Just to be clear to anyone reading along, at time of writing this bounty is still very much open and eligible for the community to scoop up.

danfinlay commented 6 years ago

we like the idea of taking the ETH you would have earned on this metamask bounty and staking it on some truffle related issue after that

To me this is the same as returning the bounty value to the pool. I think GitCoin has done a great job of actively putting bounties on all sorts of stuff, I don't have opinions on sub-pools or anything right now.

owocki commented 6 years ago

thanks for the thoughtful comments here folks. im going to ask some folks on the gitcoin slack channel what they think of the situation... truffle/metamask bounties are quite hot commodities for the community these days, so i'm hopeful they'll want to chime in

ethikz commented 6 years ago

I'm just getting into the blockchain, cryptocurrency, gitcoin community so I apologize for any ignorance that may come out as I am still learning. From what I've read here is my view/take on it, also please correct any mistakes I have as well about relationships between Companies and Projects.

I don't necessarily feel it is unethical, so to speak, for salaried OSS devs to claim bounties but could seem unfair. The perceived mission, from my perspective and maybe others, is that Consensys is paying people across multiple projects/initiatives, but still in the same space, to work full time on their initiatives. With that said, the employees have full-time work to be done to improve the technologies/efforts, and the bounties put on issues for the same reason, it is Open Source. At some point the paths will cross where salaried employees will work on bountied issues, I'm not sure there are ways of getting around it, but maybe there is.

To me, it's the same concept as being a Developer/Engineer working for a company, but in your free time you freelance and do side work or even contribute to Open Source. So why not still allow that to work the same way here? You're a salaried OSS employee working on issues the company has put forth and during your "day job," you work on those issues. When you are off work, and it's personal time then I don't see an issue claiming a bounty if you can do it, unless of course, you put a bounty on it to claim it on your off time, then yes that would be unethical. If caught, that will do the opposite of what is trying to accomplish, that, however, is a whole different discussion.

Of course what was stated:

we like the idea of taking the ETH you would have earned on this metamask bounty and staking it on some truffle related issue after that

is also a viable option if you aren't comfortable taking a bounty. It is nowhere near a perfect solution, but there will have to be trust and communication through the process.

I hope this makes sense to others if not please let me know, and I'll try to explain lol.

e-n-l commented 6 years ago

I'd say 'yes,' everyone should be able to claim / complete / collect a bounty, because a major value proposition for GitCoin is that developers getting paid to work on FOSS. That approach would also eliminate dependency on identity / employer identity, policy enforcement overhead, and generally has the advantage of simplicity.

Digging deeper, there are valid concerns that you'd be defeating that use case and inviting corruption by allowing 'insiders' who are already have contracts in place to double dip, and furthermore, may have influence on what gets a bounty to exacerbate that problem. At that point, it really is more of an internal organizational issue though... perhaps outside technical scope.

The more I think about it, the more I love the idea of facilitating bounty recycling / forwarding. Perhaps allow for organizational agreements to be part of the claim process, such that an organization could 0) pay people to spend their time on OSS, 1) have bounties claimed for that work pooled within the organization to 3) be used for posting new bounties on their own issues.

This may be simplified by simply incentivizing recycling, rather than cash out.

In any case, that would incentivize cross-pollination among teams / businesses, dramatically increase workforce flexibility and scalability: Let's say company A is in an intense sprint to meet a hard deadline, while company B completed a seasonal peak. A could place bounties to get more dev time on issues to make their deadline, which B could collect and save for the next peak season.

danfinlay commented 6 years ago

In any case, that would incentivize cross-pollination among teams / businesses, dramatically increase workforce flexibility and scalability

You just blew my mind a bit. This makes sense, if a person salaried on one team completes an issue, that bounty could be recycled under their team, making the total allocation per project more important than the division of human alignment.

Re: the double dipping: It’s not bad to do stuff on your free time, but it can be unclear which time is free and not when salaried, making it hazardous territory.

GrandSchtroumpf commented 6 years ago

Hey guys, sorry for disturbing the debate. I just would like to know if someone is actually working on this issue right now ? My company has a heavy need of events, so we're stocked with web3 0.20 until this issue is fixed...

owocki commented 6 years ago

it sounds like @benjamincburns has made some progress but is not going to claim the bounty to avoid (even the appearance of) impropriety. sounds like the bounty is back up for grabs for that reason.

e-n-l commented 6 years ago

Turns out, there's a word for inappropriately leveraging your position within a company to get the company's money into your own pocket: embezzlement

It's only embezzlement if an employee inappropriately siphons company money into their pocket. E.g., some scumbag in finance cooks the books to move money from the pension fund into some bogus investment that directly benefits him. It's a form of theft.

Bounties are already explicitly being earmarked for a purpose, and can only paid when that purpose is fulfilled. The moral quandary comes from the question of whether the employee is "stealing time" from their employer, which is outside the GitCoin scope completely; it's up to the relationship the company has with the worker.

Salary / hourly / contract are not the only compensation paradigms, obviously. In fact, studies have shown[1] that a salary + performance-based compensation structure is the superior paradigm, preferred by many professionals in roles that require significant autonomy, e.g., customer-facing / business development and management roles.

Performance-based compensation, like GitCoin, is most effective where individual performance is a) easily and accurately measured and attributable, and b) the time delta between worker action, desired outcome, and payout is minimized. Simply put, it is extremely motivating for humans to have clear, explicit incentives for tasks. Furthermore, every iteration provides an opportunity for objective measurement, feedback and optimization.

Compare that to the salary / hourly compensation model: role expectations are outlined, and a manager (usually receiving some kind of performance-based compensation himself) is required to police / babysit workers to ensure expectations are met. Absent effective systems, management and worker incentives are vague, and subjective; they often conflict with each other, resulting in exploitation and unethical behavior.

The additional layers of organizational complexity (middle management) bear a heavy cost; effective systems which increase organizational efficiency, transparency and ethicality are of critical importance to all organizations at scale. This is a class of challenges to which GitCoin, and blockchain in general, offer novel, disruptive solutions.

The big downside to pure performance-based compensation approach is that often it lacks the illusion[2] of continuity and security. The absence of assurance leads to fear, stress, and desperation, which trash productivity, makes humans stupid (literally), and creates a self-fulfilling prophecy of failure.

The salary is a clear, simple, explicit way to provide assurance. It increases the odds that the worker will successfully operate in a mindset of abundance, where they can be most effective.

Therefore, whenever possible, every company can increase efficiency and lower organizational overhead by reallocating some percentage of HR funds away from (coughmanagementcough) salary / hourly / contract compensation, into bounties for their salaried people (along with everyone else who has access) to pursue.

[1]:Full disclosure: by saying "in fact" and "studies," I mean that I have a vague recollection that I read something (possibly confabulated / entirely imagined) authoritative about this at some point in the distant past, agreed with it, and decided that it should be presented here with authority. [2]: I say that it is an illusion because there is never certainty that a company will continue employment, that it will even continue to exist. Successful contractors and free-lancers that live in 100%-performance-based-comp-land construct their own illusions of assurance, mostly from subjective confidence, with a degree of objective historical and statistical performance data. It's essentially a mental construct / model of the "manager" role, and far from invulnerable. (I speak from deep personal experience here)

danfinlay commented 6 years ago

Related to #1645.