Custom RPCs for Off-chain Data

Context: https://forum.polkadot.network/t/new-json-rpc-api-mega-q-a/3048#the-new-json-rpc-api-is-very-strict-can-i-no-longer-add-custom-json-rpc-functions-to-my-node-10

[Custom RPCs are in] one of two categories:

• Functions that are custom to the logic of the runtime
• Functions that are used internally for debugging

I want to suggest another category that we have looked closely at: Node Data Retrieval

Example Use Case (That we have investigated, but not made yet):
We have storage data that is indexed such that A -> B. Aka, if you have A you can find B, but if you have B you cannot find A without an O(n) search. The only need in the runtime is for A to find B, however "all" clients accessing the node wish to be able to discover B given A. (B->A) We could build custom logic that a node stored the reverse index (B->A) and maintained it such that then a Custom RPC could be provided that would easily be able to offer B->A lookup.

This is a "fat" node that would require local storage. It is close to off-chain indexing or off-chain workers, although it would likely not be a push, but a pull (https://docs.substrate.io/reference/how-to-guides/offchain-workers/)

The primary difference between this and the runtime situation, is that this isn't runtime logic. It would not be callable via chainHead_unstable_call.

I realize this isn't something we even use yet and nor does anything restrict adding RPCs, but I thought I would bring it as an additional category in case it was helpful.

Start with the linked forum discussion and the referenced off-chain workers guide to understand the proposed node-data retrieval category. Determine what change, if any, the JSON-RPC interface specification would need to describe fat-node storage and reverse-index lookup, and define completion criteria before implementation.