Why do we need better dApp/Wallet connectors, and how did we come up with the Tesseract protocol?

So easy your grandma can use it. It’s an ambitious goal but arguably a must for any technology to get to mass adoption. Blockchain is not an exception. While plenty of work has been done, blockchain technology is still a long way from the usability level of centralized applications.

Let me give you some examples. How many dApps are available (except wallets) in AppStore or PlayMarket? Can you authenticate with the same wallet in a browser dApp and on the phone? Can you use a native mobile dApp without providing a private key or using a centralized authenticator? How many wallets do you need to keep for various dApp interactions?

While these questions might sound like no big deal for the tech-savvy crowd, they represent a barrier for everyone else. Some of us might know the workarounds and are ok with them, but our grandmas are not. Such an approach doesn’t sound like an effective way to make dApps for everyone.

The blockchain developers’ community has brought to the table the UX skills and the experience they gained before Blockchain in Web2.0. The dApps and wallets look and feel fabulous, but the whole blockchain ecosystem is still tough to learn and use, which is a significant obstacle on the way to mass adoption. In Tesseract, we believe that the problem is not specifically in the dApps or wallets but rather in between — in the connectors that facilitate the interaction so that we can authorize transactions generated by the dApps.

Let’s bring some data to the table. To avoid overwhelming complexity, first, let’s filter out centralized authentication solutions because they don’t help us with the purpose of decentralization, and we can think of them as temporary patches. After that, we are left with the solutions that connect a wallet to a dApp using some data transfer channel (Socket, Bluetooth, etc.), and we can categorize them based on the channel type they use.

The first two rows of the table below represent a use case scenario. By the use case scenario, we mean the physical location of the dApp and the wallet (i.e., dApp is on the desktop while the wallet is on the phone). We used these as our use cases because they dramatically restrict what kind of connection (socket, Bluetooth, etc.) we can use to connect between the two.

Every connection mechanism has some use cases when it shines, and some use cases when it’s entirely not applicable. For example, Inter-Process Communication (IPC) is an excellent local connection between applications. Still, it can’t do any good if a dApp sits on the desktop and the wallet is on the phone.

Here is a table we’ve made to summarise the above:

The table above shows clearly that no single transport (connection type) can cover all the use cases, thus telling us that no single connection mechanism is sufficient as a universal solution dApp to Wallet connector.

This simple fact inspired us to build a protocol not affected by transport (Socket, Bluetooth, etc.) constraints. We have added some requirements on top (decentralized, chain agnostic, etc.) and devised a flexible solution capable of connecting a dApp and a Wallet with the best transport available regardless of the blockchain protocol used.

To achieve this level of flexibility, Tesseract utilizes a layered architecture, somewhat similar to OSI or TCP/IP model.

TCP/IP is well known for its resilience and flexibility as the primary internet protocol. The comparable layered architecture provides Tesseract with similar advantages to potentially handle any known or future use case to the extent the most matching transport can, which is not an option for single-transport bound solutions.

This significant advantage opens the possibility of having a universal link between any dApp and wallet, which we aim for with the Tesseract protocol. We believe that such universality is the key to making Blockchain so easy that anyone can use it.

The Tesseract protocol stack is implemented in Rust and thus can be used anywhere Rust can be used. The current implementation (alpha version at the moment of writing) and supporting documentation can be found here: https://github.com/tesseract-one/Tesseract.rs. Currently, we are working on getting the first blockchain network (Polkadot) integration and adding the IPC transports for iOS and Android.

To find out more about Tesseract’s current stage, plans, and tech details, please, check out the following grant proposal: https://github.com/w3f/Grants-Program/blob/master/applications/mobile_dapp_connection.md for Web3 Foundation, who is supporting Tesseract. TLDR; after finishing with mobile, we add desktop dApps support and more blockchain networks.

This article is the first one in the series about Tesseract. We will post on Tesseract’s development progress regularly here, or you can follow us on social media (Twitter: @tesseract_one) or GitHub (https://github.com/tesseract-one/). The next one is coming once we get IPC transport working on mobile and have the Polkadot blockchain support to showcase how Tesseract can make Blockchain easy for everyone, even Grandmothers.

Stay tuned!