everyone!
It’s Josep from Parity 
.
I had initially planned for my debut post in this forum to delve into the exciting projects my team at Parity has been engrossed in over the recent weeks. I was looking forward to revealing this in a few weeks from now, anticipating some truly groundbreaking showcases. But, given the mentions by @bkchr, it seems apt to at least provide a brief introduction about our current endeavors, our approach, and the vision driving us.
Before diving into that, I’d like to resonate with some poignant thoughts shared in this discussion. I particularly align with this insight by @tomaka and this comment by @bkchr:
We as Parity are here to help, but we can not fix everything. We are also much more concentrated on the low level stuff and are better in providing show cases/prototypes for people. I hope that we can finally find a way to put more stuff into the ecosystem, because only a working ecosystem will make Polkadot a success, not an ecosystem that is just Parity et all. Parity should be a minority, an actor in the ecosystem and not more!
Contradictory? Not in my view. I -like @bkchr- also really hope that we “can find a way to put more stuff into the ecosystem”. In my perspective, the inception lies in providing an accurate and up to date specification.
On a thrilling note, thanks mainly to @tomaka’s contributions, we now possess a light-client friendly JSON-RPC spec. This sets the stage for some of the most exciting developments from my team. But without further ado, let’s delve into what exactly we are formulating.
In essence, we’re focusing on crafting a composable, modular, and “light-client first” alternative to PJS. Our paramount aim is to equip dApp developers with the tools necessary to construct genuinely decentralized applications, all while ensuring a stellar developer experience. This is achievable thanks to our simple yet powerufl API complemented by robust typings.
Additionally, through a CLI, types will be auto-generated, enabling dApp developers to select the chain interactions vital to them, such as storage entries, transactions, events, constants, and errors. These “descriptors,” as I presently term them, represent the minimal units describing a specific chain interaction. This flexibility extends further, allowing developers to choose descriptors across multiple chains for crafting multichain dApps. Even descriptors from different runtimes could be utilized, ensuring dApps are prepared for particular runtime upgrades.
Our client will offer an API that will signal in real-time which of the provided descriptors align with the runtime of the currently connected chain. This real-time communication allows dApp developers to adapt to runtime upgrades as per their requirements.
Moreover, we aspire to ensure this top-level library, designed for “ordinary” dApp developers, is underpinned by small, composable building blocks. These blocks are intended to assist advanced developers in creating their unique tooling or bespoke solutions.
There’s a plethora of additional details I’m eager to unveil about our ongoing work. Rest assured, I will elaborate further on these soon, certainly before the year concludes, and likely in about a month or so.
You might be wondering why I haven’t used this forum earlier to shed light on these developments to the community. Personally, I lean more towards action rather than words. I firmly believe in letting our work speak for its caliber and impact. This doesn’t mean that comprehensive documentation will be overlooked. On the contrary, while striving for a tool that’s intuitive and straightforward for the fundamental and prevalent functionalities, we will ensure that ample resources are available for understanding and utilizing the full scope of our project.
My emphasis is on dedicating time to refine and enhance our work rather than promoting it prematurely. This stance doesn’t diminish the significance we place on feedback. Active engagement with various teams within the ecosystem is a consistent effort, ensuring our direction aligns with the collective needs and expectations. Showcasing our progress to these teams allows us to corroborate that our path is attuned to the larger goals of the community.
I invite you to observe our ongoing work at our GitHub repository. Despite the absence of official documentation at this juncture – a reflection of our compact team (3 devs) and the prioritization of development pace – advanced developers can glean substantial insights into our current accomplishments by exploring the public APIs, package tests, and contents within the “experiments” folder of the monorepo. In fact, I’m aware of at least one team in the ecosystem which is already using our work 
.
In closing, while numerous aspects and details have not been covered in this brief overview, rest assured, a more systematic and comprehensive explanation is on the horizon. Your patience and continued support are immensely valued as we navigate this journey of innovation and growth at Parity. Stay tuned for more detailed updates coming your way soon!