Are you building an EOSIO application or have already built one, and are looking to integrate Anchor Wallet with it? Without diving into too many implementation specific details, we’re going to dive into some of the things you’re going to have to think about from the user/frontend development perspective.
During the development of these applications, at some point you’ll likely want an end user to identify themselves, sign-in, and be able to create transactions on an EOSIO-based blockchain. As an application developer you most likely shouldn’t be dealing with keys or end user security, so the proper path to go down is to integrate with an existing “signature provider” (wallet).
So how would you do this in your app? You’ll want to venture into a somewhat new realm of technologies, commonly referred to as the…
Wallet Access Layer
All of these types of activities fall under the umbrella of the wallet access layer (or WAL for short). It’s an abstract term that covers “how your end users interact with a users wallet”.
So the first decision as a developer you need to make is:
- Do you want to create your own wallet access layer?
- Do you want to use an existing wallet access layer?
This decision is very similar to the decisions you’d make about writing your own CSS vs using bootstrap, or writing your own database adapter vs using an ORM.
Each has their own strengths and weaknesses.
| Strengths | Weaknesses | |
|---|---|---|
| Create one | Very flexible, created to suit your needs. | High difficulty, little community support. |
| Use existing | Low difficulty, standardized approach. | Less flexible, might not work for all use cases. |
Many early adopters of EOSIO were forced to create their own, which has created situations where it’s difficult now to support additional wallets. Luckily now the choice exists!
Integrating directly by creating your own WAL
Going this approach you’ll likely use eosio/eosjs at the core of your project and then integrate with the wallet specific libraries to add support for each. This would include libraries like greymass/anchor-link to integrate directly with Anchor, GetScatter/scatter-js to communicate with Scatter, etc etc.
Every different wallet you’re looking to onboard will require some level of abstraction, since each wallet provider requires different parameters during setup, while creating transactions, and even returns differing levels of data based on the response of the request.
You’ll also have to consider integrating:
- Authentication mechanisms for each wallet supported.
- Session persistence, how and where that information is stored.
- Abstraction of each wallet providers returned data into an interface your app understands.
It’s a large effort - but for big/long-term projects, that effort might be worth it.
Integrating using a pre-existing WAL
By implementing an existing WAL into your application, most of the difficult processes in performing the integration is removed and you’ll easily be able to add new wallets as they become available. It’s a great place to start and as a developer, lets you bypass the complexities of building your own system to manage this communication.
At this point in time there are a few choices within the EOSIO ecosystem that you can choose from, with the most widely used being:
- eosio/universal-authenticator-library: A library for allowing apps to easily use different auth providers.
- eosnewyork/eos-transit: Transit Wallet Access Layer for EOS blockchain networks
Both of these libraries offer a plug-in like interface that allows you, as an application developer, to choose which wallets your application will support. From there, each wallets specific plugin will return results to your application in a consistent manner.
You’ll still end up likely using eosio/eosjs, as these libraries expose its underlying functionality, but you’ll also gain the benefit of:
- A common set of methods for authentication.
- Built-in persistence and management.
- Updates from both the library maintainers and plugin maintainers.
So which do you choose, UAL or Transit? This leads to the next series of considerations and a decision you’ll have to make for your users. Here’s a brief rundown of a few of these as you’re making your decision:
Customizing the UI
These two libraries offer distinct approaches when it comes to the user interface itself.
UAL approaches this aspect of WAL by providing a built-in UI that prompts users to select a wallet provider which when selected connects to the appropriate application. This interface cannot be customized and is similar across all applications that use UAL. This offers benefits in a familiar experience across any application that uses it.
Transit leaves this aspect of development up to the application developer, which allows the developers to build any custom experience they want for their users. It exposes the functionality needed for you to connect to the appropriate wallets and create a bespoke experience from start to finish.
Supporting Multiple Accounts or Blockchains
At the time of writing, if you want to support multiple accounts/blockchains in your application, there’s only one choice: Transit.
UAL is currently built in such a way that you initialize it with a blockchain and the tailored user experience is designed to get them logged in with that blockchain. Transit on the other hand, with the ability to create a custom interface, allows applications to be built that support both multiple blockchains and accounts.
For this reason, you’ll want to select Transit if you:
- Want to allow users to switch accounts without having to sign-out of one account and sign-in to another.
- Want to allow users to switch between various EOSIO based blockchains and remember which accounts belong to which blockchain.
It’s a more complicated integration - but some apps may require this.
Long term support for WAL platforms
This one is a tricky one, and I only bring it up because it’s something you should consider - but I don’t personally have a great answer to it. Not having to worry about the WAL breaking (
) or being able to find support and development is an important part when choosing open source tech to integrate with your project.
UAL is a labs project created by Block.one and Transit is a project that was created by the former EOS New York team. Neither have had substantial development recently, and to be honest the future of both is somewhat in question.
What cannot be questioned however is the value that WAL-type projects bring to developers. This ecosystem need a stable framework on which developers can integrate now and not have to worry about it being unsupported in the future. That sort of certainty helps choose the right direction, aside from the features in question.
Until there’s a good answer to the above question, myself and other members of the Greymass team plan on trying to support both until we know more about the future of both of these frameworks.
Ultimately, it’s up to you.
So which is the right path for what you’d like to build? It’s a hard question to answer without context of what the project is. If you’ve got questions, feel free to join in the discussion below and ask questions that matter to your work.
I would however recommend that if you’re just starting out, pick a WAL framework and use it until you out grow it. If your project is big enough and warrants developing your own code to go without one, that sounds like a good position to be in. For the beginning stages of a project though you should take the path of least resistance, as your project is what matters, not how you reinvent the wheels for it.