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.