There are several issues with the current fiojs library. These are not necessarily “showstoppers” for integrators, but they can increase integration complexity:

  • Mycelium has expressed concern regarding the number of 3rd party libraries included with our Kotlin SDK.

  • Some wallets have asked for a better understanding of the encryption libraries included in fiojs and how they relate to eosjs.

  • When creating tools that interact with FIO, the encryption libraries present a problem because they are somewhat non-standard.

  • It is difficult to integrate with other EOSIO tools because of our use of encryption and some other non-standard interactions.

Proposed Changes

Several options were discussed with Jimmy regarding the different options for minimizing the pain of keeping up with eosjs and eosjs-ecc changes. We also reviewed other forks of eosjs. The following are the options:

  • Keep as is. Maintain a separate copy of eosjs and manually merge in commits we think are important.

    • Pro: no changes to current process

    • Con: hard to know what changes are important and you can get into a bit of merge hell when you cherry pick.

  • Create a complete separate fiojs that wraps eosjs and eosjs-ecc

    • Pro: This would be clean, would clearly separate out fio code, and would allow devs to use eosjs completely separately from FIO.

    • Con: This will require a lot of rework of our code and is not simple.

  • Create a fork of eosjs and eosjs-ecc and merge in our fio code

    • Pro: This makes comparison of upstream changes easier to compare and pull in.

    • Con: It is not a “clean” separation of FIO code.


  • Move from a separate copy of eosjs to a fork of eosjs to make it easier to merge upstream changes from eosjs. We would then review commits and do regular merges from eosjs when we do fiojs release.

    • 3/16/21 update from Eric: We may want to consider more drastic updates to fiojs to get it more in line with eosjs or other eos libraries. Need to scope.