Standardize and simplify serialization and encryption libraries
The encryption used in FIO Requests and OBT Record actions is non-standard
There are issues with the fiojs library including encryption libraries, difficulty of integrating with other EOSIO tools, and maintaining a copy of eosjs
I’ve had good success so far using AnchorLink, though it is front-end specific and currently requires Anchor. That said, under the hood, is EOSIO Core which seems to be a useful improvement over eos.js or fio.js and it supports FIO well (such as allowing you to pass in a legacy prefix such as FIO when getting public keys).
I think this is a really important problem to overcome. It should be easy for any developer to quickly work with OBT data, send, receive, cancel, and approve FIO Requests without having to import tons of extra code or libraries or sdks, especially if most everything of what they want can be done via things like EOSIO Core from Greymass. If existing tools for interacting with EOSIO chains will work well with FIO, we should embrace them and provide very minimal code needed to do FIO specific things.
We also need to figure out how “authenticator” wallets like Anchor, Metamask, and Ledger (hardware) wallets can work with OBT data. What’s the path of least resistance for them to get up and running quickly? What’s the minimal code footprint we’ll be asking them to introduce? How will this work with secure enclaves coming in the future with crypto-enabled hardware devices like phones.