The MVP version of #3639, a refined version of the older/messy #2350.
To allow dapp developers to use web3 1.0 in the least possible time, we could add support for the "subscription" API (provided by websockets normally), even over our current polling-based HTTP connection.
This will involve adding a subscription subprovider (very similar to our current filter subprovider to MetaMask's current provider, which is composed from json-rpc-engine as viewable here. A subscription subprovider already exists in a similar but incompatible form in provider-engine here, and that one can be used as a model.
Major differences between the provider-engine and json-rpc-engine versions:
provider-engine subproviders are objects with a handleRequest method. json-rpc-engine subproviders are simple functions.provider-engine handlers take three params: (payload, next, end). json-rpc-engine breaks params into two params: (req, res, next, end).- provider-engine included a reference to a block-tracker, json-rpc-engine is unaware of the ethereum protocol, and so subproviders need these data sources passed in as function parameters.
Additionally, these subscriptions should not persist with each individual page, and should clean up themselves. One approach to this we've explored in the past is to initialize this "subscription" not in the main network provider, but in the inpage provider which pipes each page's API requests into the core MetaMask process. This allows the memory management of the "fake" (client-side) subscriptions to benefit from the browser's own content-script memory management.
When this works, users should be able to import web3 1.0 and use the subscription API with no issue, like this:
// Importing the latest version from NPM
const Web3 = require('web3')
// initializing a local instance
const web3 = new Web3(window.web3.currentProvider)
web3.eth.subscribe('logs', {
address: '0x86fa049857e0209aa7d9e616f7eb3b3b78ecfdb0', // EOS token is popular atm.
topics: [], // A token transfer log would be good for now.
}, function (err, result) {
if (err) throw err
console.log('Success!', result)
})I will try to continue refining and updating this spec here on the parent comment to minimize required reading.
Some other optional approaches to solving this issue are reviewed in this comment.
A brief summary of the architecture involved in this feature is in this comment #3639.
Bounty information
Because we have moved our develop branch over to json-rpc-engine, which lacks subscription support, this issue is now a deploy-blocker. We never officially supported the subscription method before, but it was merged in, and since trying to publish our latest version, we've become aware that several major dapps and at least one framework (Drizzle) build on our subscription support. This dramatically increases the urgency of the completion of this feature.
To be paid out, the bounty hunter should:
- provide a subscription middleware
- include tests similar to the previous subprovider.
that at least matches the coverage of the previous implementation.
- should perform at least as well as the previous implementation.
This is a contest-type bounty, and so multiple devs can take up the cause at once, but we will only pay out an acceptable implementation, so please do communicate as you progress, and ask about any major tradeoffs you're considering making.
We will also be pursuing this feature, but since we have been so slow to complete it, we invite you to race us, and get credit for this valuable feature.
The MVP version of #3639, a refined version of the older/messy #2350.
To allow dapp developers to use web3 1.0 in the least possible time, we could add support for the "subscription" API (provided by websockets normally), even over our current polling-based HTTP connection.
This will involve adding a subscription subprovider (very similar to our current filter subprovider to MetaMask's current provider, which is composed from json-rpc-engine as viewable here. A subscription subprovider already exists in a similar but incompatible form in provider-engine here, and that one can be used as a model.
Major differences between the
provider-engineandjson-rpc-engineversions:provider-enginesubproviders are objects with ahandleRequestmethod.json-rpc-enginesubproviders are simple functions.provider-enginehandlers take three params:(payload, next, end).json-rpc-enginebreaksparamsinto two params:(req, res, next, end).Additionally, these subscriptions should not persist with each individual page, and should clean up themselves. One approach to this we've explored in the past is to initialize this "subscription" not in the main network provider, but in the inpage provider which pipes each page's API requests into the core MetaMask process. This allows the memory management of the "fake" (client-side) subscriptions to benefit from the browser's own
content-scriptmemory management.When this works, users should be able to import web3 1.0 and use the subscription API with no issue, like this:
I will try to continue refining and updating this spec here on the parent comment to minimize required reading.
Some other optional approaches to solving this issue are reviewed in this comment.
A brief summary of the architecture involved in this feature is in this comment #3639.
Bounty information
Because we have moved our
developbranch over tojson-rpc-engine, which lacks subscription support, this issue is now adeploy-blocker. We never officially supported thesubscriptionmethod before, but it was merged in, and since trying to publish our latest version, we've become aware that several major dapps and at least one framework (Drizzle) build on our subscription support. This dramatically increases the urgency of the completion of this feature.To be paid out, the bounty hunter should:
that at least matches the coverage of the previous implementation.
This is a contest-type bounty, and so multiple devs can take up the cause at once, but we will only pay out an acceptable implementation, so please do communicate as you progress, and ask about any major tradeoffs you're considering making.
We will also be pursuing this feature, but since we have been so slow to complete it, we invite you to race us, and get credit for this valuable feature.