JSON RPC Spec & Testing Community Call Nov 27th
=======================

8am PST, Nov 27th

Agenda: https://github.com/spadebuilders/community/issues/15

Zoom Video: https://zoom.us/j/946476323

EthMagicians Discussion / Follow up Notes: https://ethereum-magicians.org/t/json-rpc-specifications-and-testing-community-call-nov-27th-2018/2031

## Action Items

Everyone review the PR of the spec
* https://github.com/ethereum/EIPs/pull/1474
* Chris L volunteered to be a maintainer
* let's push for Last Call so this can get nailed down

Boris to setup separate repo, it may be easier to collaborate there than just in a single PR thread
* https://github.com/spadebuilders/ethereum-json-rpc-spec

Should there be a separate process for proposing JSON-RPC extensions?
* breaking changes and/or major additions to the spec should likely be filed as EIPs
* for convenience, working group have a separate repo
* need to start working and see how it evolves

Stakeholders include:
* client devs, those looking to build a new, compatible client
* middleware -- web3js, ethers.js --> definitely need
* devops / people looking to run many nodes
* miners

Middleware Flags for Debug
* many dapp developers don't know that JSON-RPC exists -- blame middleware for errors
* talk to middleware about a debug flag or common approach to get at underlying responses

Testing
* INFURA has released compatibility / interop testing https://github.com/INFURA/rpc_sanity_test
* Bob pointed to Casey's tests here http://cdetr.io/eth-compat-table/ -- which is an RPC test suite https://github.com/cdetrio/interfaces/tree/0fcb796440dea702e308710457346d29b051f365/rpc-specs-tests -- part of Hive https://github.com/ethereum/hive
* INFURA can be involved
* Dave said he'd be interested in testing
* loop back with Piper

EEA
* Boris to coordinate with Ron / Chaals / Alex at EEA
* Loop in Ben Burns as EEA technical lead?
* How will EEA contribute?
* Likely next step is an internal EEA call with interested members & clients - Block Apps, Quorum, Clearmatics, Pegasys, etc.

## Notes

Introductions

Boris Mann

Bob Summerwill

EG Galano - Consensys, Infura
* feel this pain
* digressions between clients
* open sourced

Ryan
* Infura
* getting multiple clients agreeing on responses
* generally spots where we can clean up responses

Chris Leishman
* Core Engineering Consensys
* core ETH protocols that we can do to move things forward
* technical product manager -- APIs and specs consistent

Dave Appleton
* use GO a lot
* using Parity and Geth, different backends
* replacement for EthClient because of differences

Charles
* Polymath work on open source dev & community
* adding value

Antoine
* core engineering consensys
* working on a client Elixir / Erlang -- right JSON RPC

Paul Cowgill
* working on Tasit Labs https://tasit.io
* building an SDK for making standalone mobile dapps
* JSON-RPC batching signed messages for

Alex
* consensys
* working with EEA on organizing task forces
* educating EEA members on how to get involved

===

What are clients doing now in attempting to build compatible specs?

Intersection between Geth / Parity, then try and do what's next and attempt to pick between the two

Repo for JSON-RPC spec, tests
- doesn't need to be in one repo, but does need to be run independently

This is part of broader spec process, Boris has PR against EIPs repo to highlight these sub-specs, would like to list maintainers for each of them

Do people know who maintainers are for other specs?

* devp2p
* Felix Lange changed the wiki page last time

Whisper

---

EEA interest
* Compliance process
* Solid spec to build on
* Point

Proposal for upgrades to spec
* as EIPs, or?

Doesn't lead to hard forks?
- shouldn't be too rapid an iteration
- which clients support it will dictate what how much usage
- web3js, ethjs, metamask, custom dapps

The spec was Ethereum wiki pages, when Parity left, they made their own pages
* No coordination mechanism done
* Fork and another clients

Current spec, large amount of undefined behaviour

Start of EEA -- efforts which Dan Finlay and Casey Detrio and others had done at a hackathon in Seattle
* trying to build tests
* some of the push back from Parity
* overspecification was a problem
* overspecified -- that's bad as well

Stakeholders as mentioned above about spec changes
* large scale
* mining, not a lot of ambiguity
* came out during testing -- JSON-RPC is stateful, get different answers -- challenge to test

Testing?
* any tests
* hive test repo --> Peter Sz, can we use those tests
* what does interop mean?
* not just tests -- its running across different clients
* compliance vs other clients
* sync up to a certain level, should see same blocks
* http://cdetr.io/eth-compat-table/
* add a column -- stability -- likelihood of breaking changes

Can have things rolled out whenever

Middleware
- very often when breaking changes or errors
- developers only understand middleware -- not what JSON-RPC is
- in the future, if we can think of ways we can work with middleware providers to better expose underlying RPCs that are having an issue
- large number of dapp developers don't really know about this
- maybe debug flag? best practice -- documenting what the call underneath is

Infura, testing
- working on hiring
- can be involved, can't take it all on

EEA Working Group
* not sure when to happen
* Ben Burns spec?
* Ping Ron Resnick -- cc people who expressed interest

Clients that will be compatible
* list?
* quorum
* block apps
* clearmatics
* pantheon

Ben Burns Ganache CLI
* supporting all devs
* doing testing on their laptops
* dapps are going to get right results on mainnet
* can run in two flavours -- geth or parity
* Ben was harsh on how bad it is
* middleware perspective

Ganache until recently encoded numbers incorrectly

Dave
- test suite willing to work on

EEA could help in creating test suites, modular pieces

Developer evangelism -- if test suite looks like the hive test suite
Client developers will want to be on the list

Lots more develop than we have in a long time

Post Shanghai, clients died -- now with ETH2, more client dev than ever

Hinting at JR-IP process
* two concerns
* one issue -- non breaking changes can go through
* breaking change needs to go through EIP
* discoverability of separate process
* might get separate issues

Want to get to canonical specification for all of these things -- the Ethereum platform

EIPs are the way of making changes to that

EIPs are the working notes -- I have to read all of these???

Imagined that we'd end up with a single, broader paper

EIPs are working through changes

PRs against the original paper

Could be a single thing

Is that over constraining? Maybe tieing them all together isn't great -- for Whisper and Swarm as an example

Somewhat concur with that -- single specification for each piece of the protocol, whether single doc or not

Would want there to be versioning

Not try and boil the ocean -- RFC, which version

Should be able to do the same with EIPs

###### tags: `ethereum` `json-rpc` `community call`