EOSCommunity.org Forums

The missing features of a wallet abstraction layer

I’m creating this post to start keeping track of what’s missing in the current wallet abstraction layers. I’ll start off with the features I know are missing, and would welcome other developers using UAL and/or Transit to chime in and leave notes on what they believe is missing.

  • Interfaces for Resource Management: Right now we have Fuel baked into anchor-link, but can’t extend it out to other wallet providers via UAL or Transit because it happens after the request is already determined to be routed through ESR. If the resource management interfaces were added into the wallet abstraction layer, any wallet would be able to use providers like Fuel.
  • Extendable session storage mechanisms: Currently both UAL and Transit use embedded localstorage mechanisms to save and restore sessions. This cannot be extended to use things like cookies should the site need it. The interface to save/restore sessions should be possible to override for situations where localstorage is not sufficient.
  • Signing an arbitrary string
  • Implementation modules independent of the main repo, possibly with a versioning on the module that the abstraction layer can inspect to determine compatibility with future features/APIs
  • Being awesome like everything Greymass creates
1 Like