The Transit API: Connecting dApps & Signature Providers
User experience is king. The Transit API is an open-source standard that allows for easy compatibility between the best signature providers and dApps in an easy-to-use API and minimalist footprint.
Early Adopters
Thank you to Everipedia, BancorX, AIKON, eosDAC, Greymass, SimplEOS, and Chintai Team for implementing Transit API and/or supporting it in the future.
Transit API Developers Group:
The Problem
User experience is the rightful king but doesn’t always get to wear the crown. Does your favorite dApp support your favorite wallet? We hope so but there are significant technical barriers for that to happen consistently.
When a dApp developer gets to the point of supporting multiple wallets for authentication and transaction signing for the end-user to choose from (like METRO hardware wallet, Ledger Nano, Scatter, etc), he would need to set up eosjs API instances for each, track the connection/authentication state, user authentication data and EOS account data, handle connection errors, manage disconnected wallets, get the app notified when some wallet internal state changes, etc. This is a lot of redundant work. In addition to this extra workload, dApps developers need to seek out new signature provider solutions and manually add support creating a dynamic where the best user experience may not always win.
The Solution
The open-source Transit API covers these aspects for the dApp developer. It’s basically what a dApp developer would have written on his or her own in one way or another. The Transit library is a tiny abstraction layer on top of eosjsand aims to assist EOS dApp developers with wallet communication (in order to sign the transactions) through a simple and intuitive API.
This allows one to concentrate on building awesome apps instead of setting up eosjs and wallet connections.
- Easy to use API
- Managed wallet connection state tracking
- Easily pluggable wallet providers (and easy to write your own)
- TypeScript support
- Small footprint (core is just ~9Kb minified and around 2.7Kb gzipped)
Basically, we’re aiming to cover the entire “Login with EOS” use case for a dApp by making it as easy as installing few packages (core and necessary providers) and using the rather minimalistic API.
The Nuts & Bolts
The Transit API is a small convenience wrapper around eosjs (core) and some code that communicates to 3rd-party wallet apps for transactions signing (wallet providers). It’s not extending the EOS blockchain, nor does it extend these 3rd-party apps, it just provides the consistent glue between these pieces of tech, while also providing some assisting capabilities like state tracking for wallet connections.
The Transit API is minimalistic and does not act as an obstacle, providing many escape hatches (i.e. there is always a reference to underlying eosjsAPI instance available on Transit API wallet instances) and only doing what its designed for.
There are 3 core pieces of Transit API:
1. WalletAccessContext are configured wallet providers in the context of a given dApp (identified by the passed app name when created) on a given network (defined with a passed network configuration). This keeps track of configured providers and is responsible for initializing wallets and tracking their state. Performs initial eosjs RPC access configuration.
2. WalletProvider is a piece that communicates to a particular 3rd-party application. As the name implies, it “provides” the access to that app in a consistent manner (there’s a WalletProvider API defined in Transit API). It’s not in any way bound to the WalletAccessContext — one can even use the WalletProvider instance directly if needed. Doesn’t track state or anything, but provides the actual functionality to connect(), login() to the wallet, etc. The actual implementations are not the part of Transit API core and are maintained and installed separately.
3. Wallet represents a certain WalletProvider connection in a certain WalletAccessContext. It basically wraps the WalletProvider (there’s a provider property on a Wallet) and adds some contextual metadata to that — it tracks if the wallet is connecting or authenticating if it's connected or authenticated if there’s a connection or authentication error and keeps the related data. The actual eosjs API instance is created on the Walletinitialization and is maintained as an instance property.
To get started, please see our full guide. We have put an emphasis on making the documentation as robust as possible.
The Road Ahead
Transit API is currently in open beta and we invite the developer community in EOS to contribute. The investment in Transit will blossom when developers are able to focus on the user experiences that are layered on top of Transit. Just like how Wordpress websites are able to apply different “skins”, we envision a future where talented UI developers build “Skins” and screens for the login experience. Different web frameworks like React and Angular will have their own nuances. It is our hope that the developer community will take advantage of Transit API in order to create the best user experience for the end-user. Currently, a Scatter plug-in is ready to go and we are busy building additional plug-ins like with Lynx, Ledger, and more. We encourage all signature providers to build their own to increase the value of this standard to the community.
Block Producers as Builders
This project is open-source, cannot be monetized, and required significant time and investment. Through block rewards, Block Producers are perfectly positioned to build foundational tools like these, returning those rewards back to the network in the form of added-value and code. Please support block producers who are committed to this type of reinvestment, it is critical to the growth of EOS.
