The new IOTA Client Libraries: Harder, Better, Faster, Stronger

Over the years a lot of developers in our ecosystem have been using our client libraries to integrate IOTA into their applications. Available in many different programming languages, both officially supported and community driven projects made it possible to utilize the IOTA tangle in many projects: From IoT devices using the C library to web applications in Node.js, Go or Python.

In early 2020 we started making plans to improve this experience with the learnings from the past years.

We came up with a solid plan and decided that the Chrysalis release, focusing on a production ready and user friendly IOTA, makes it the ideal moment to replace our existing libraries and move forward with an easier, more robust, sustainable and standardized solution, which we are introducing now, in light of IOTA’s “new dawn”.

The core principles of the new libraries

After working with the existing client libraries for several years and supporting countless community developers with their projects we had a fairly good idea about the aspects we could improve upon.

Some of the things we often heard were statements like “There are too many things I need to learn about IOTA before I can get started” or “Feature X is only supported in language Y”.

We collected all our own experiences and the community and enterprise feedback and came up with a set of core principles for the new client libraries:

Bindings, a single source of truth

Up until now every language has had its own set of supported IOTA features and ways of accomplishing certain tasks. This could sometimes lead to confusion among different implementations and clearly was sub-optimal.

With the new libraries we decided that there should be only one reference implementation for the client libraries (we've chosen Rust for this) and all other implementations should follow that reference implementation in terms of naming and functionality.

To enforce this and to utilize the security features and performance of Rust we decided that the new libraries should utilize the Rust reference through bindings to ensure the exact same behaviour and the exact same functionality in any supported language. What this means is that you can actually use our Rust libraries directly from your favorite language in your favorite syntax, bringing the power and performance of our Rust based library to your language of choice. At the moment of writing we have bindings available for Node.js and Python and are actively developing additional bindings for Java and other languages.

Easy to use, but as advanced as you might need

The previous libraries were created with maximum flexibility in mind. Literally every option available in the protocol could be used from the clients, but this also meant that you need to know a lot about how the protocol itself works before you could make use of it to its full extent.

With Chrysalis we decided to improve this experience and come up with as many sensible defaults as possible. Previously you had to manually provide your node URL, convert/encode your transaction, set up the options like “minimum weight magnitude” (MWM) and “depth” before you were able to use the libraries. In the new version however these are all provided by default under the assumption that you want to work with the mainnet, using the default parameters for the mainnet and that you are encoding your data in (utf-8) bytes. This results in a much easier to use library for everyone, even if you never worked with IOTA before.

If you don’t supply a specific argument it uses the default; If you don’t want the default behaviour you can overwrite this behaviour to make all advanced use cases possible as well. This allows us to offer a new library that is both easy to use and has all the functionality built in that you’d ever need.

Helper functions

There are some patterns while developing with IOTA that are quite common; for example finding a public node to use. This used to be a manual job, but with the new client libraries you can just tell it to use ‘mainnet’ or ‘testnet’ and it will automatically find a synced public node for you through our helper function. Another nice helper function we offer is the abstraction of events.

In the past you had to use a separate third party library to connect to the nodes’ MQTT/ZMQ feed for events, now you simply have the option to listen for events directly from the client libraries by providing your own callback function if an event is triggered.

These and more helpers are already available to use right now with the new client libraries bringing another level of convenience to the IOTA developer experience.

One wallet library to rule them all

Previously every IOTA implementation that handled IOTA tokens did its own implementation using the core client libraries which is quite low-level. This was quite a bit of work and as every implementation is different, it sometimes resulted in incorrect implementations.

To remediate this issue once and for all we introduced another brand new client library, wallet.rs. Wallet.rs essentially is a programmable wallet that we encourage to use for every implementation that handles IOTA tokens. This stateful library takes care of everything for you including things like synchronization and security. Wallet.rs is already integrated into the new Firefly wallet, the Command-line wallet and the testnet faucet, and allows any developer to implement an own wallet where the critical core components are handled by the library.

Some of the highlights of wallet.rs are:

• It’s stateful, so fast to use even if you have many addresses and accounts
• You can make as many accounts as you like with their own options; Manage both test and mainnet accounts in a single wallet.rs setup if you wish
• It’s secure by default, using Stronghold for secret management
• Sending and receiving funds is easy, if a re-attachment is ever needed it will handle it for you
• Backing up and recovering the state is a built-in feature

The same principles applying to the core library apply to wallet.rs as well. The library is easy to use with sensible defaults and has bindings for Node.js, Python and Java with more potential languages to be added later on.

Other libraries

Regardless of how much we like our new approach it’s not a solution that’s ideal in every possible situation. For these cases we have other libraries available as well, but with a more limited functionality:

C libraries for low powered devices

C is a low-level, highly performant language used a lot in embedded devices with limited resources. Because of some of the limitations that come with Rust bindings for embedded devices we decided we’d still create a separate library for C. This library handles all basic interaction but does not offer wallet.rs like functionality or most of the helper functions from iota.rs.

Native Go and TypeScript library

We also offer a native Go and TypeScript library that do not utilize the Rust bindings. This has to do with the fact that we already needed to use these libraries before iota.rs was available. We are considering offering bindings for both as well at a later stage but these libraries can already be used if you wish to utilize IOTA technology using Go or in a web-browser.

Watch the video about the new client libraries!

Conclusion

With the new client libraries we bring a whole new level of usability, flexibility, performance and professionalism to the IOTA ecosystem making it a true joy to work with them. They are available right now to be used on our Chrysalis testnet and will replace the existing libraries once we launch Chrysalis on mainnet.

The client library including bindings can be found here, with initial documentation here. For the wallet library see the wallet.rs repository on GitHub and the initial documentation for it.

We can’t wait for you to try them out! If you have any questions, please feel free to join our Discord and chat us up.