The Future of UAL (or another abstract authentication standard)

Problem

There are multiple authentication schemes used in EOSIO right now, different wallets have their own API.

It is not easy for dapp developers to implement all these multiple login options. There are many existing dapps that still only support Scatter login, some might never be upgraded again to support the most popular wallet at the time. For example trying to write an adapter of the very specific Scatter API approach to the Anchor API does not seem feasible: https://github.com/greymass/anchor/issues/951 (that brief discussion is recommended for additional context).

Discussion

In the future this situation should be avoided by establishing one standard that is flexible enough to have adapters written for more specific wallet APIs.

One attempt at such a more abstract standard was UAL. But it has never been widely adopted.

Open questions

  • What are the main reasons UAL hasn’t been adopted thus far?
  • What are the major shortcomings of the current state of UAL?
  • Is it feasible to continue iterating on the UAL model or is another abstraction necessary.
  • What are the pros and cons of all the different current authentication methods?
  • How can we educate each other and the wider public better about the clear advantages of solving the authentication problem to make more of a priority?
  • Or are there actually good arguments to not try to push for one such standard and let the open market compete on different proprietary protocols?
1 Like

UAL has seen decent adoption over the past few months since we’ve been encouraging it to developers looking to integrate Anchor, but you are right in that it’s never achieved wide adoption by any of the ecosystems. I would say out of all of the Anchor-integrated apps, the vast majority (I don’t have a specific number) have done so using UAL or Transit.

Before I jump in and engage on some of the questions, I do want to reference this post I wrote a while back about the decision to use or not use technologies like UAL:

With that being said, I wanted to take a bit to dive into some of the questions above and give my opinions and hopefully some answers on some of the open questions from the OP.

I think the answer to this one is many, which includes:

  • Awareness: The documentation out there for new EOSIO-based application developers on the subject of wallets is incredibly sparse. If you head on over to Google and try doing some searches for guides on the subject, you’ll have a difficult time finding one, let alone one that guides the developer to use something like UAL.
  • Technical Debt: Libraries like UAL didn’t exist early on, which is likely when a lot of the more successful EOSIO-based apps were developed. The first UAL release was ~9 months after the launch of EOS, and early applications had to handle this type of development on their own. Because of the way all of this unfolded, the early developers accrued a lot of technical debt that now would need to be paid if they were to replace all of their custom code with something like UAL.
  • Foundational Development: Both UAL and Transit are groundbreaking projects, but neither of at this point are actively being developed or advanced to support the features that app developers need. As EOS and other networks continue to evolve, the needs of these libraries have changed to now include things like resource management.

This, and more aspects of the “why”, could all probably be summed up by saying “they never hit the point where they were feature-rich enough for adoption”.

I personally have been the primarily person on our team driving integration of anchor-link, our wallet-specific implementation library, into both UAL and Transit - which has given me some insights into where this stack is lacking currently. Much of this insight came from trying to develop identical example applications using our native library, UAL, and transit. These 3 demos are available here for anchor-link-demo-multipass, ual-reactjs-renderer-demo-multipass, and eos-transit-demo-multipass.

This demo was designed to be a multi-account, multi-chain, and multi-device demo to highlight implementation details and feature capabilities. The major findings were that:

  • The UAL version of the demo is not capable of handling multiple accounts at the same time. The sign-in mechanisms in the library are designed for a single account and the UAL specification and library itself would need to be changed to allow multiple accounts at the same time.
  • The UAL version of the demo is not capable of handling more than one blockchain at the same time. You can allow the user to swap blockchains by reinitializing UAL with a different chain id in the application code, but as you switch chains UAL will attempt to use the account from your previous chain if you attempt to login.

It’s probably feasible to continue on it, but it would need a major rework (v2 release) that would likely be incompatible with v1 of the specification. This of course could be a completely new library that adopts and learns from UAL, but for purposes of adoption may be better to keep under the UAL brand.

Are we talking about UAL vs Transit, or anchor-link vs scatter-js?

A good question, and I think starting a discussion like we have here is one of the first steps.

As for priority - there is an incentive problem. For teams like ours, our internal incentives stops at the wallet sdk itself for the most part. Speaking for our team specifically, the vast majority of our effort has gone both directly into the wallet itself and the sdks directly for it, and we have only reached out into the UAL-like libraries when in dire need.

However when we talk about something like UAL v2, that’s where the wallet developers are not incentivized specifically to engage. We have had a lot of internal discussions about trying to take over development of either UAL or Transit, or even just taking a much more active role in their evolution, but with our team being as small as it is we have a hard time justifying that effort when our products ultimately deserve that attention more since that’s likely where our revenue will come from that sustains our organization.

These wallet abstraction libraries are truly a “public good”, and without getting too political, the economic incentives to build public goods has declined over the years. Organization, unless completely self-funded by some other means, are having to pay for these types of developments on their own. That severely limits the scope of these goods and services as they’re developed.

I don’t think there is a good argument to not push for a standard. If we don’t have a standard, I think in the end it’s the users that end up suffering and having a bad experience, which then causes EOSIO-based applications to suffer in adoption.

It’s my belief that in an ideal ecosystem, the following is true:

  • The end user of an EOSIO-based application can use the wallet of their choosing anywhere.
  • The developer of an EOSIO-based application has guides, tools, and SDK(s) available to make it so they only have to integrate one thing into their application, and all users can access it.
  • The developer of an EOSIO-based wallet has guides, tools, and SDK(s) available to integrate their signature provider into the SDKs that the application developers are using.

This seems achievable with a global EOSIO standard like UAL. It’s just going to take a Manhattan-project style effort of time and money to achieve though.