Overview

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.

Recommendation

• 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.