I stumbled upon this idea once more.
I would like to try and solve this, but from a very product oriented perspective: Let’s identify a few known pain points, and build tech that exactly solves that, rather than the opposite.
Raising this, as there are multiple options:
- raw runtime apis, for exmaple the one proposed in Kusama: Make the current inflation formula adjustable. by kianenigma · Pull Request #364 · polkadot-fellows/runtimes · GitHub
- view fn, drafted in Implement pallet view function queries by ascjones · Pull Request #4722 · paritytech/polkadot-sdk · GitHub
- XCQ, being worked on by @xlc in GitHub - open-web3-stack/XCQ: Cross-Consensus Query Language for Polkadot
From a technical perspective, all 3 have non-overlapping properties, so a native solution is to build all 3. But let’s first ask which one is the low hanging fruit.
I have a few examples of such low-hanging fruits, but I won’t reveal them to keep the conversation unbiased.
To that end, I am writing this to make a CTA to all TS of those who have coded TS in our space to comment:
When was the time when you were working with
api.query, and you felt the most pain? This pain could namely be due to:
- You needing to re-implement (possibly changing) onchain logic in TS
- The storage you were reading was too complicated/low-level