API Migration path for non-Javascript users

[Crypto2]

Hello,

We've been using the Lisk API for years and see now things like account/open and submitting transactions no longer support the 'secret' field and tells you to use Lisk Elements (which appears to be for Java only) or Lisk Commander which is a command line app, not a library.

What is the proposed upgrade path for non-Javascript users? (ie. nearly all exchanges/hosted wallets/etc.)

[MaciejBaj]

Hey, Lisk Commander is a command line tool it will be suitable for non-JS users as well, here - #2368 it's described how to create an account.

[Crypto2]

So your real upgrade path is really to shell a command line tool? And nobody brought this up or thought about non-Javascript users at all during this whole 1.0 development process? Good lord.

[ghost]

@Crypto2 As far I know, except mine Lisk-PHP library, which support all/most latest functions. https://github.com/karek314/lisk-php
There are also, Swift and Python libraries.

Here is example of generating account with Lisk-PHP
https://github.com/karek314/lisk-php/blob/master/lisk-cli.php#L248

Sending transactions
https://github.com/karek314/lisk-php#as-library-in-project

[got3nks]

I'm wondering why they were removed from the API, as @Crypto2 pointed out I guess most of exchanges were using those API calls.

[ghost]

Because these endpoints were just stupid by design. You were sending request to other machine, usually external server which returned you account private key, that solution assumed trust in that server. While no matter what it should be trustless.

[got3nks]

Makes sense.

[Crypto2]

@karek314 I doubt anyone was using it that way since as you said it would be stupid. People were of course running their own Lisk nodes either on the same machine as their code or in a trusted VPN/SSH tunnel/etc.

[willclarktech]

Hi @Crypto2, our mission at Lisk is to make blockchain accessible. That includes both developers/blockchain creators and non-technical users. While it may be obvious to people familiar with blockchain technology that sending secrets to others' nodes is a bad idea, it's not always obvious to those who are new to the area, and in fact we became aware that some people were sending their secrets to nodes they didn't control. Removing these endpoints was the most direct way to guarantee that this security issue disappeared.

In order to make progress as quickly as possible, Lisk focuses on providing reference implementations in a single language (as is the case with many other projects), and JavaScript is our language of choice given the aim of increasing accessibility. We encourage and support community members such as @karek314 who desire Lisk functionality in other languages to build their own implementations, and you'll probably find more support on lisk.chat from community members regarding such implementations.

Although we have no plans to build libraries ourselves in languages other than JavaScript, we do provide a CLI (Lisk Commander) which exposes most of the important functionality found in Lisk Elements. While this is indeed not a library, for some non-JavaScript users who are unable to find (or create) a community-driven library in the language of their choice, a workaround may be to make system calls to Lisk Commander from within their scripts.

Regarding the specific use cases you mentioned:

1. account/open: We recommend (and in some of our software assume) passphrases using words from the BIP39 wordlists. Our transaction signing/verifying is based on ed25519. These are standards which apply beyond the realm of Lisk, and there are libraries implementing the relevant functionality in many different languages.
2. Submitting transactions: Once you have a signed transaction object, submitting it to a node just involves sending an HTTP request to the API. You can use your HTTP request library of choice. As for creating the transactions locally, it should be straightforward to construct JSON object using the schemas specified here: https://lisk.io/documentation/lisk-protocol/transactions (or to use a community library if available).

If you have any further use cases which aren't covered here, please get in touch using lisk.chat or Gitter for assistance.

As a final point, I'd like to draw attention to the version numbers involved here. The recent release of Lisk Core had the version 1.0.0 partly because this is the first release which has an API we are satisfied with. In general, software which has not reached version 1.0.0 should be treated as highly experimental and any API it exposes should not be assumed to supported in future.

[got3nks]

@willclarktech I agree with your points but the biggest issue at the moment is caused by bugs in lisk-commander, as you can read here: LiskArchive/lisk-commander#605

[willclarktech]

@got3nks Acknowledged, we're working on a solution for that issue and will keep you updated there.