KINtroducing: kin.js

Ever since we started the Kin journey, we’ve focused on native mobile apps. Since our state of mind is to build only what we need, web and JavaScript technologies were not a priority. We have chosen to implement some server components in Node.js, but these projects (while open-sourced) are mainly used internally. The SDKs we offer do not include a JavaScript version.

Recently I published a new kin.js project in our Github which will hopefully kickstart a new and lasting relationship between Kin and JavaScript. The publication of kin.js did not escape the eyes of our community, and I’ve decided to write this post to convey the reasons behind this project, its current state, and future goals.

Motivation

We are the first client of the JavaScript SDK, as we need it for our internal services and tools (which are completely public and can be used by anyone who desires to use them).

The JavaScript ecosystem has matured and grown to such a level that it’s becoming more and more difficult to find software projects which don’t use javascript to some extent (after all, most projects, at least, have a website). It is therefore clear why we hear requests from developers and partners for a JavaScript SDK, with more projects now relying on Node.js and alternatives to mobile native, such as React Native and Ionic. Due to the increasing interest in a JavaScript SDK, we are now starting to give this the attention it deserves.

Goals

Support major javascript runtime environments

Currently, this means Node.js, browsers and javascript-based mobile app frameworks, but as the Kin Ecosystem grows, the need to use Kin in other javascript environments might emerge. It’s too soon to know, but keeping in mind how versatile javascript is, we are designing the SDK in such a way that its core will be runtime-agnostic.

By using TypeScript, we’re already getting closer, as TypeScript can transpile our code into different environments.

Abstract the underlining blockchain implementation

Good libraries hide the specifics from their clients and offer a comfortable interface to the desired functionality which the library aspires to serve.
With this in mind, the Kin JavaScript SDK will try to abstract the blockchain components and functionality so that developers won’t need to have the knowledge to carry out the operations used for the everyday scenarios (which will grow in number as Kin becomes widely used).

This means that users of the SDK won’t need to be aware of the blockchain functionality, abilities, or even terminology. You shouldn’t need to know what we’re using behind the scenes when using the JavaScript SDK.

With that being said, sometimes developers need more “low-level” APIs and functionality, so we’ll address it if the need surfaces.

Encourage community support

As a Kin employee who lives through the everyday creation of this new ecosystem, I can safely and honestly say that, in our eyes, Kin belongs to everyone, it’s not ours, and indeed during my occasional strolls through our Reddit I find myself humbled time and time again by the level of support from our community. Because of this, I’d be very surprised to learn that developers in our community are not waiting for the opportunity to help, try, test, fork, develop, embed, and use kin.js in ways we haven’t even thought of yet.

It will take time, but we’ll work on making it as accessible as we can so that you will all be able to contribute.

Current State

Currently the JavaScript SDK contains only a Kin client and can only run using Node.js. It was created to be used internally in our marketplace system tests (mock_client.ts / client.ts). We already had most of the client functionality scattered around, so I decided to extract and distill it into this new project.

It is currently only targeted for Node.js because we use it to mock clients in our tests. Making it available for other runtime environments is on our list (more on that later). It was easy to start with the SDK for testing as it doesn’t (directly) affect production.

The client provides the following functionality:

  • Create/load a Kin wallet
  • Pay to address
  • Get past payments
  • Subscribe to a new payment event

The following code snippet shows how to use the above. We have decided to develop in TypeScript, and so the snippet (and our documentation) will be in TypeScript. It shouldn’t scare JavaScript developers as distribution files will always be js (accompanied by .d.ts definition files).

Using the Kin Client in Node.js

The library works well, even with limited functionality, and it can be used as long as its users understand that it will probably change greatly in the near future.

Next Steps

I suspect that as this project progresses it will evolve according to the requests and needs of our partners, developers, and ourselves. It is impossible to predict those needs and the timeline for them, but here is where we currently see this project heading (remember that all of this is extremely speculative and may change drastically):

1. Finalize the client

While the client works great, it lacks tests, which are needed to complete this stage. The tests will likely consist of unit tests and integration tests with our blockchain.

2. Node.js server component

While it is possible to use the client for multiple wallets in a server environment, it will require the developer to manage those wallets. Additionally, it might not scale well. To solve these issues and grant more server-oriented API, we’ll provide a server component which will:

  • Create, load, fund, and manage multiple Kin wallets
  • Pay to address
  • Subscribe to Kin payments for any given address
  • Support high volume of transactions (by using Stellar channels)

We will then use and test this component by porting our current payment-service to JavaScript and using the SDK. By dogfooding it (something we take very seriously) we’ll make sure that we offer a component that can work and scale for partners and developers.

3. Browser and mobile support

While this is probably what people are looking for most, we still need to figure out the needs and the use cases. Major issues here are the responsibility of saving the private key for the user, and other security concerns we haven’t started to appreciate.


Summary

I hope I was successful in communicating where Kin currently stands in relation to JavaScript and where we plan to take it. I’m thrilled to finally introduce a Kin SDK for the JavaScript web developers out there, and while it is still a work in progress, it is a great addition to our toolset that will help us expand the Kin Ecosystem. We’ll update on the progress being made, and you’re also welcome to follow the project repo.

If you have any questions you can comment on this post, ask in our Reddit, create an issue in our Github repo, or ask a question with a kin tag in Stack Overflow.

Links: