PSP6 is extremely poor, technically speaking

[tomaka]

PSP6, introduced in #6, specified a list of JSON-RPC functions by simply copy-pasting the ones that are currently in use.

The problem is that nobody (at Parity or outside) has actually really ever worked on polishing these JSON-RPC functions. They were added at will, accepting every Substrate PR that adds or touches a function without really thinking about it.

The consequence is that these JSON-RPC functions have a lot of defects. Rather than copy-paste a list of defects, I'm going to link to the first section of this hackmd that I wrote a long time ago: https://hackmd.io/fvwtpwrVTg-fUScreohOsw
Of course some points regarding documentation do not apply because you did a great job documenting the format of the functions, but documenting the functions doesn't remove most of the core issues in them.

One of the major issues with these JSON-RPC functions is that they can't be properly implemented by a light client. If you build a tool on top of these functions, and connect to a light client, your tool will not work properly. Some tools just can't be built on top of light clients, but most of the time it's just because the tool needs to be able to handle some corner cases that don't happen when connected to full nodes.

Having this list of JSON-RPC functions as some sort of "standard" gives the impression that we're committed to these functions, but it is very much desirable to get rid of them in the future.
Some time ago I've started https://github.com/paritytech/json-rpc-interface-spec/, which has the objective of replacing these JSON-RPC functions with better ones.

[FlorianFranzen]

First of all, I totally agree. The RPC-API needs a refactor.

The consequence is that these JSON-RPC functions have a lot of defects. Rather than copy-paste a list of defects, I'm going to link to the first section of this hackmd that I wrote a long time ago: https://hackmd.io/fvwtpwrVTg-fUScreohOsw Of course some points regarding documentation do not apply because you did a great job documenting the format of the functions, but documenting the functions doesn't remove most of the core issues in them.

You are welcome to provide your proposed changes as a PR to PSP-6. We are just getting started and changes are expected.

Having this list of JSON-RPC functions as some sort of "standard" gives the impression that we're committed to these functions, but it is very much desirable to get rid of them in the future. Some time ago I've started https://github.com/paritytech/json-rpc-interface-spec/, which has the objective of replacing these JSON-RPC functions with better ones.

I do not see how that is a problem or inaccurate. Until we have a better solution, we are committed to these function. We have four hosts and various clients (incl. polkadot-js) using these RPC calls. So even if we came out with a better API, it will take time for all hosts and clients to switch.

[burdges]

I'd suggest we rename this repository to "Polkadot (Non)Standards Proposals" for a year or so. ;)

[danforbes]

This Issue brings up some very good points, but the title is a little distracting and not very effective in terms of communicating those points concisely - maybe something like "PSP6 - Problems & Suggested Solutions".

I agree with Florian that it's important to commit to and support some standards - Polkadot is well "in production" since the launch of parachains and as Florian points out there are a number of teams building on Substrate/Polkadot "as a platform".

Looking forward to following these improvements...great work, guys 🚀

[tomaka]

I just want to mention that I disagree with the fact that any reference to the JSON-RPC protocol should be found in the Polkadot specification.

A client implementation should be able say "we are compatible with the Polkadot spec and with the standard JSON-RPC protocol", but these two things (the Polkadot spec and the JSON-RPC protocol) should IMO be two completely separate things.

[alxs]

While it is currently referenced in the spec, that's pretty much the current wording. Implementors are encouraged to implement an API, but they don't need to and it doesn't need to be this PSP. I don't think there's anything wrong with one standard referencing another.

@FlorianFranzen: @tomaka has picked up work on the new API he shared above and Parity has already started working on it. I guess we should spread the word and get other implementors to follow suit? At what point do we endorse the new one? Ideally we can just refer Pioneers Prize implementors to the new one, but that would mean that it would need to happen pretty soon.