Summary
As part of the Inbot platform which has its own token on Stellar, we've been developing our own Kotlin OSS client for Stellar that adapts and extends the existing Java SDK. This has served us well and the Kotlin Wrapper makes using Stellar quite easy relative to the Java client which is tends to require more boiler plate.
Over the past few months, we've been thinking about logical next steps for us on the OSS front and identified a big opportunity: Kotlin is becoming a full stack language and it now makes sense to implement a cross platform Kotlin client for Stellar. A cross platform approach would allow us to use the same Kotlin client on several platforms including those currently covered by the Java SDK.
Goals
Develop a cross platform Kotlin client that uses the kotlinx frameworks that can replace the existing Java client for Android and backend use cases as well as be of use targeting other platforms. The goals here are not to just match the existing clients but to take the learnings from developing our Kotlin wrapper for the java client and provide a best in class implementation that is easy to use, supports all relevant features related to Horizon, Federated accounts & compliance, supports both synchronous and asynchronous ways of using the client, and implements error handling and retries.
A secondary goal for this project would be to also upgrade the Command Line Interface for Stellar (CLISTE) that we bundle with the existing wrapper to use this to provide a native command line experience for Stellar. The goal with this would be to act both as a show case for the client and make full use of the multi platform nature by packaging this up as a native client that can launch quickly. The existing command line has been instrumental for us while we were developing Inbot and it will help new users and expert developers to get started. We want this client to be
- scriptable, pipes & filter friendly, etc.
- support human readable as well as machine readable output (e.g. CSV).
- user friendly
- fast
- facilitate Stellar use both for managing wallets and exploring the block chain and the distributed exchange
Description
Why Kotlin
- Kotlin is increasingly used as an alternative to Java on both Android and Backend and Kotlin native is increasingly important for cross platform native projects on IOS and Android. Finally the native and javascript compilers are also potentially interesting for addressing other platforms such as Web Assembly in either browsers or serverless environments or native desktop applications
- Being able to use the same client across different platforms simplifies development and allows people to keep stellar related business logic portable.
- Kotlin is emerging as a very capable language and has recently been endorsed by e.g. Google for Android development and Spring for backend development.
Kotlin multi-platform projects can currently produce output for several platforms: JDK 6 and 8, Native IOS/Android/Linux/Mac/Windows/WASM, and JavaScript. A typical multi-platform project has a shared Kotlin codebase with platform neutral logic and several platform specific variants that deal with the specifics of each platform such as crypto, networking, asynchronous computing, etc. Kotlin has various emerging cross platform frameworks under the Kotlinx umbrella that provide cross-platform solutions for this with platform specific implementations that you can plug in. E.g. KTor provides a cross platform http client that can use e.g. okhttpclient on the JVM, the browser fetch API when running in a browser, or e.g. curl in native platforms. There is is ktotlinx.serialization for providing cross platform JSON marshaling and kotlinx.io provides useful cross platform abstractions to deal with byte streams.
Motivation
What's wrong with the existing Java SDK:
- It lacks features. E.g. dealing with federated accounts, error handling, asynchonous networking.
- It targets Java 6 because Android does not support language features introduced later such as lambdas, Java streams, type inference, etc. Kotlin provides this and more for both Android and the Backend.
- It is low level and requires a lot of boilerplate code.
- It's awkward to use from Kotlin, which is something we addressed with the current wrapper but limited by the underlying Java implementation.
Platforms and intended users
Currently there are three separate Kotlin compilers:
Kotlin JVM - compiles Kotlin to Java bytecode that is usable for both server side and client side Android development. Kotlin has been endorsed by Google as the main language for Android development and e.g. the Spring project has also identified it as the preferred language for future development and explicitly supports Kotlin as of Spring 5.x and Spring Boot 2.x. Kotlin for the JVM has been designed from the ground up to facilitate co-existing with existing Java code bases and it is easy to use Java code from Kotlin, or the other way around.
Kotlin-native - As of Kotlin 1.3, this compiler is in a beta state. It currently builds on top of the llvm compiler tools and is able to provide outputs for IOS, Android (native), Linux, Windows, Mac OS, and Web Assembly. The main development focus currently is on mobile development for supporting cross platform, native mobile applications built in Kotlin. Cross-platform native Kotlin libraries are also easy to consume from e.g. Swift projects on IOS or from Flutter based applications on either web, IOS, or Android.
Kotlin JS. This is a transpiler that produces JavaScript that can run in a browser. It is similar to TypeScript. E.g. frameworks like KVision provide elaborate support for developing UIs in Kotlin and can be seen as an alternative to e.g. Vue.js or React.
Given that there are several pre-existing SDKs for Stellar already, the focus with this project would be on these platforms (in order of priority):
JVM for Android and Backend. The intention of this would be to provide a replacement for the existing Java SDK with friendly Kotlin centric API that is also usable from Java projects. The main focus of this project will initially be serving these two ecosystems.
Native IOS and Android for the purpose of e.g. using the Kotlin client in Flutter, React Native, or similar cross platform native applications where it is desirable to have a native client that is the same on each platform. We believe using Kotlin for cross platform native mobile application development makes a lot of sense already and is likely to grow more important with the upcoming Kotlin releases.
Native Linux, Mac, and Windows - We need this to implement a native command line client for Stellar. Additionally, there is an obvious benefit for using native Linux in the context of e.g. server less computing where startup time is essential. Serverless is in our opinion a very appropriate paradigm for Stellar based backend software and using a native client for this would be desirable to minimize resource usage and startup time. Windows support would of a lower priority as it would be possible to just use the linux client there via the linux sub system for windows. Additionally, C# may be a more logical choice for e.g. Windows Desktop or Server applications.
Native WASM. The Rust ecosystem is leading the way in this space and has been an early adopter of WASM which they treating as a first class citizen. However, it is our view that Kotlin has similar potential as a logical alternative in this space with support for WASM already present in its native compiler. With things such as WASI and widespread support for WASM in browsers, a cross platform WASM Kotlin client for Stellar would be able to be used in a wide variety of use cases ranging from Browser applications, microservices, command line tools, and server-less environments. However, it is early days for WASM in the Kotlin community and we anticipate major changes through the next year on this front before this becomes a mainstream option. The intention with supporting this from day one would be to be future proof.
JS. Kotlin is currently not a mainstream choice for this and other clients already serve this space. However, the compiler actually works well and is stable. So, we may end up supporting this anyway just because we can and because we like the idea of using Kotlin for web application development at Inbot.
Scope of the work
The cross platform client
- Support the full Horizon API
- Provide support for marshaling XDR, crypto.
- Federated + compliance APIs for dealing with federated accounts.
- Provide a developer friendly API surface that deals with error handling and provides sane defaults that aims to minimize boiler plate without taking away user friendly-ness.
- Be testable and IOC (Inversion of Control) friendly. This means, Constructor injected everything, no magic numbers, and trivially easy to use whether your application uses Dagger, Spring, Koin, or simple DYI dependency injection.
- Provide a great experience for beginning Stellar developers who are just discovering the Stellar platform.
- Provide a migration path for existing users of the existing Java sdk.
- Replace the current Kotlin wrapper with the new client.
CLISTE - the Command Line Interface for STEllar
As part of developing the original Kotlin wrapper for the java sdk, we developed a command line tool. As we built Inbot, this has proven surprisingly useful as a thing to have. Dealing with e.g. the API explorer and wallet UIs to perform routine setup of accounts on e.g. test and standalone networks can be tredious. As part of this effort we would want to:
- Make this a separate project that depends on and forms a show case for the cross platform Kotlin client.
- Provide Linux, Mac, and possibly Windows native command line clients.
- Support all horizon operations including streaming operations.
- Support multiple outputformats, including csv style output, json and jsonline based formats, and any other formats that make sense for automated processing
- Support inspecting XDR as well as preparing transactions in XDR format or signing existing ones.
- Make the client scripting and piping friendly. There is a big use case for e.g. using this in combination with other command line tools such as csvkit, sort, awk, etc.
Stellar OSS project contributions
We've been contributing to Stellar with pull requests on the Java SDK and xdrgen. Part of this work will require more work on these projects. Anticipated work would include
- Kotlin generator implementation for xdrgen
- Clean up the xdrgen architecture to support this
- Possibly backport some of the Kotlin work back to the java sdk where this makes sense (e.g. using the Kotlin model classes instead of the current Java ones).
- Continue to support both projects with pull requests for maintenance and bug fixing as we have in the past year.
Use of funds
This currently is not a full time project for us and we've so far not had a lot of third party contributions. Making progress on all of the above is going to require dedicating serious amounts of time. It is a big commitment. In so far this aligns with Inbot goals, we do some of this, but beyond that a grant would help us make progress here much more rapidly and allow us to involve more developers.
We'd also be looking to engage other developers to accelerate the development. All code developed under this effort will be open source (MIT License).
If you wish to contribute, contact us or start collaborating on Github. We are currently tracking requirements and feedback here
Links
