node interaction library for Dart

[andrzejchm]

Currently, there are two libraries for Dart to interact with the Cosmos-based blockchains:

• Sacco
• Alan

and both of those libraries have their drawbacks:

• sacco uses amino under the hood, which is now considered deprecated
• Alan relies heavily on gRPC and only in some degree on LCD

Both of the libraries haven't seen the updates for the past 12 months making them pretty hard to use on a newer version of the cosmosSDK, which heavily relies on RPC and LCD communication.

Possible solutions

💡 Contribute to the Alan library by submitting pull requests with updates and new features

✅ pros:

• requires the least amount of time and maintenance on our side

❌ cons:

• we're relying on an external repo and the willingness of the maintainers to merge the PRs and release new versions
• it's not future-proof as new features might require ground rework of the entire library

💡 Fork Alan library and continue developing it further as part of the ignite organization

✅ pros:

• we have full control over the code and the repo

❌ cons:

• still might require ground rework of the library to add new features

💡 Wrap the CosmJS libraries with flutter using either flutter_js or js

✅ pros:

• we don't have to worry about the implementation specifics and rely on the CosmJS developers
• maintainability is reduced only to making sure the interfaces for the dart->js interactions are up-to-date with each version of cosmJS.

❌ cons:

• interacting with JS library from dart is rather experimental and might cause a lot of headaches.
• debugging will be very limited (there's only ability to invoke the javascript code and inspect the results, no in-between breakpoints and analyzing the JS code in runtime)

💡 Write the library from scratch based on the CosmJS implementation

✅ pros:

• we have full control over the code and the repo
• from the public relations perspective its another tool inside the Cosmos ecosystem provided by us giving the impression we have a very broad accessories list available for developers to use
• we can make the code adhere to the dart code standards within the organization

❌ cons:

• requires the most amount of time, will be costly in the beginning

[andrzejchm]

I invite you to have a look at this and share any info or feedback you might have on this topic @wal33d006 @Zfinix @fadeev @eitjuh @akc2267

[wal33d006]

Given the conditions, and circumstances, I would suggest the last option. Writing the library from scratch.
The biggest reason I think of is we aren't live yet and we can give it the time it requires to develop. Secondly, the effort and time would be worth it since the library implicitly becomes a part of Ignite as discussed.
Had we been already live and our application running out there, this wouldn't have been a good choice, but considering all the facts and the point where we stand, I think we should go for the longer and stable route.
Let's see what other people have to say because this is my perspective as a core developer, maybe this route has some red flags from a company's vision perspective or maybe something not suitable in the long run.

[Zfinix]

I also agree, in time you'll see that the complexity of maintaining a JS Wrapper version will increase and it would be better to have just rebuilt from scratch, luckily i have alot of experience porting JS Code to Dart lol. I agree with @wal33d006

[fadeev]

Thanks for researching this @andrzejchm 🙌

Wrap the CosmJS libraries with flutter using either flutter_js or js — I agree that complexity will creep up on us and we'll have to rewrite the thing anyway eventually.

Contribute to the Alan library by submitting pull requests with updates and new features — Alan isn't that well maintained (wrt to active contributors).

I'm torn between:

• Fork Alan library and continue developing it further as part of the ignite organization
• Write the library from scratch based on the CosmJS implementation

Really depends if it saves our time to start from Alan rather than from a clean slate.

[andrzejchm]

Since we already have pretty solid fundamentals done with the transaction_signing_gateway library, we could simply in the beginning implement transaction signing and broadcasting using the TransactionSigner and TransactionBroadcaster interfaces, similar to what we currently have with AlanTransactionSigner and AlanTransactionBroadcaster. We can of course base those implementations on how it is currently done in Alan and from that point onward we should be fine with ditching the Alan library from Ignite CLI template and other mobile apps completely.

This should not take too much time and will prove to be future-proof allowing us to easily add new features later

[andrzejchm]

As discussed today, we'll introduce a separate package that will miimc the stargate functionalities and will be used to (at first):

• derive wallet from mnemonics
• sign transactions
• broadcast transactions.

I'll create issues specifically for that and we can focus on technical discussions there.