add eth_listTransactions #123
Conversation
|
See a relevant discussion here: trufflesuite/ganache-cli-archive#45 |
|
An unfortunately stalled idea, for both technical and some philosophical reasons. More discussions: I am increasingly in favor of cultivating a more experimental ecosystem. There is a serious technical reason that retrieving transactions is expensive, but this shouldn't need to dictate the available JS apis, and we should aim to make each interface as hospitable to its users as possible. I'll just plug this here, I have hope that the upcoming EIP Signaling DAO could help clients coordinate around enhancing features like this: |
|
@axic my bad, should have checked |
|
@mvayngrib you may be interested in: https://github.com/kumavis/eth-tx-finder |
|
Oh, this is just for the etherscan subprovider? I think this is actually an acceptable addition. Etherscan provides it, so why not let users of that subprovider use additional methods? It's not part of a web3 browser, but if you're using the etherscan subprovider, it's because you're pointing directly at etherscan for your data. |
There was a problem hiding this comment.
I thought more on this, and discussed it with @kumavis, and we think it's OK to add this to the etherscan subprovider, since it's a service they add.
This won't be added to MetaMask's provider, it's just for users who are composing their own etherscan-backed provider engines.
The explorer was nothing different in fairness. It mapped to etherscan as-is and was open to be filled by other providers. I think this is more dangerous than the explorer was, because this pollutes the |
|
Sorry for merging before opening for more discussion. I guess we could consider reverting this still. I'll share more of my reasoning now. Why is this dangerous? I think there is actually very little risk. The worst thing I could imagine happening is that some consumer tools that rely on this method emerge, and people prefer and rely on those tools, and then suddenly all the web3 browser vendors and client developers have extra community pressure to figure out how to add If that did happen, what it would represent (to me) is the beginning of a division between "bare minimum node-syncing API" provider methods, and "useful for interfaces" provider methods. The web3/RPC APIs have been bare-bones for quite a while, and I think there's going to be an increasingly strong motion for more API-like query methods, like IPLD-selector, SparQL, and state subscriptions, that allow richer, more dynamic interfaces. Maybe this isn't the right place to make this stand, but at some point clients are going to have to grow beyond individual transaction requests, so that they can load more useful data at once, and I think listing transactions is a humble enough example of that to make a point that some providers might add richer UX methods as a sort of proposal to the wider community. I still think we should strive to make these additions widely publicized, so that other client developers can more easily support compatible methods themselves, which is a good job for the universal specs proposal. But until then, I'm personally leaning towards being more tolerant of light support of non-standard methods, especially in the case of non-injected providers, like this etherscan provider is. When developers are using the etherscan provider, it's because they're not using a web3 browser or environment, and so they are not really creating compatibility issues between web3 browsers, instead they're just getting a richer experience, which is why I don't think this creates the same kind of dangerous compatibility schism that is created when Parity and Mist implement different versions of |
|
Oh all that said, I'd also be happy just moving this to something like an @mvayngrib how would you feel changing this from |
|
@FlySwatter i don't have a problem changing it if that's the consensus |
non-standard, but useful (to me :)