#365·Sublab proposal #DOT-1: Substrate client improvements, ecosystem tools, and Kotlinization

Dear community,

We're proud to present our next proposal from the Sublab team which primary focus is on developing tools for developers in Substrate ecosystem. This proposal is published after 10 days since the discussion was published.

Please feel free to read the full proposal document at this link: https://docs.google.com/document/d/10ipyb2_d1d9FCYY4Xp3aRi5CZmZJOzbqBZ50hQMerUI/edit?usp=sharing

Context of proposal

sublab.dev is the California based company designated to develop fully native open-source libraries for mobile platforms in Polkadot and Kusama ecosystems, covering everything with reliable unit-tests and providing rich documentation to the developers community.

We've recently finished our very first proposal within which we created 13 Swift and Kotlin repositories to operate with Substrate networks. While we have basic functionality, we still need to develop more features to reach current ecosystem state and its functionality. Also, we agreed to collaborate with a couple of projects in ecosystem to develop base SDKs for their services in Swift and Kotlin, and chose extra providers to develop SDKs for, which cover most popular functionality in mobile applications. Furthermore, we now seek to make our Kotlin libraries be written fully in Kotlin and use only Kotlin libraries so that we can make our libraries ready for Kotlin Multi Platform.

This proposal is expected to be a first step out of two in series of milestones to come as close as possible to current ecosystem state. Also next milestone is suppose to cover improvements/fixes to existing libraries and more collaborations.

What we're trying to accomplish within this milestone

Most of our efforts are projected to be put into Substrate client we made for Swift and Kotlin.

Primary purpose is to create pre-created set of models and functionality like popular and common between all networks constants, storage queries, functions and events, so end developer will not need to always write boilerplate code. This potentially saves thousands of hours if we take into consideration multiple teams working with these libraries. Also we want to boost our extrinsic service to have all day-to-day methods in it: fees estimation, transfers, batch requests, and so on.

Secondly, we want to develop special manager which will be capable of handling hundreds of simultaneous clients at the same time. Mobile devices even though they're powerful nowadays still not almighty. Application sandbox is limited, thus in order to work with many networks in parallel we wish to create set of functions and classes which will be responsible for turning on and off all clients depending on current app function optimizing CPU and RAM usage.

To make this manager it's also needed to have some caching mechanism: we propose to create a database which will be responsible for storing everything from these multiple connections, work with pre-defined common constants, storage queries, functions, and events, combining everything together to speed up and optimize cold and hot starts of Substrate client instances.

Last but not least part of Substrate client improvements in this milestone is to provide support to work with all existing parachains. Every network has their own runtime which sometime differs very much. So we look forward to create as many as possible unit tests to check compatibility of our Substrate client with every existing parachain today. Indeed this would require a lot of internal client changes. So we will do our best to keep our codebase clean and tidy, and at the same time powerful to handle dozens of different networks, and hundreds of connections.

Also, in this proposal we're looking forward to making a set of small libraries to provide SDK interface to most popular block explorers which are used for fetching history and many more: SubQuery, Subsquid and Subscan. For now, we decided to develop basic interface so that we don't dive too deep into all functionality and get burden of supporting it all. In this proposal we want to provide functionality that allows developers to use all of the service features, but maybe with small tweaks. However, we might find some solutions to do later to optimize and avoid this extra customization. As extra, there will be couple of token/fiat exchange rate resolvers to choose from.

In parallel, there are two small projects. Provide Combine interface in our Swift libraries so that Swift developers can choose what asynchronous approach they would like to use in their application. And Kotlinization. This is very special project for us: we have created a few of libraries in Kotlin from scratch like schnorrkel algorithm. And since we still rely on some Java libraries, it is not that easy to make our Kotlin libraries compatible with Kotlin Multi Platform. This technology opens a big opportunity to use our libraries in many different platforms from mobile applications to web, so we're encouraged to make our libraries ready for this bright future.

Our mission

We want the Substrate ecosystem developers to just do brand new features to make the ecosystem richer and be recognizable by even more people around the globe, while we can hold their backs by doing a great infrastructural work. We want to see more mobile apps in the ecosystem either from existing parachains to launch their own apps or absolutely new mobile wallets with more innovative functions. Same we want to help existing applications by solving their core issues within our works and help them adopt our products. Also we aim to partner with as much as possible existing networks and/or companies who already deliver their services to ecosystem, so that even their products might be easy accessible via reliable SDKs.

Proposal financing and deliverables

We're requesting $259,500 for the current milestone which includes improvements to existing Substrate clients, SDKs for block explorers and currency exchange rate providers, adding Combine interface to Swift libraries and migrating our Kotlin libraries to use only Kotlin, not Java dependencies. Each part is planned to be released separately and sequentially along with publications to public package managers' repositories, as well as on our GitHub for a review. Also we're planning announcements on our Telegram channel and future Medium blog with a brief description of deliverables. And in the end when we finish documentation part we're going to publish on-chain report with appropriate links to the open source code, package managers' repositories, our articles on Medium, and links to documentation website (https://docs.sublab.dev)

Epilogue

We look forward to hearing from you any constructive feedback and/or questions regarding our planned works. Feel free to refer to our proposal document

Sincerely,
Sublab team