Challenges of Building a DApp Wallet

By Jon Purdy
AIWA Project Manager

We started building AIWA (short for Aion Wallet) in July 2018. We built AIWA to satisfy a need: Aion users needed an easy-to-use wallet that is available on the platforms they use the most (like web browsers), and developers needed a tool that would save them time so that they didn’t have to interact with Aion wallets directly.

Building our DApp Wallet, AIWA, was incredibly rewarding but it wasn’t easy! The team encountered a number of roadblocks that we had to overcome. I’ve detailed them here.

Figuring out the differences between web3 and aionweb3

One of the biggest differences between the two libraries is that web3 has promises, but aionweb3 has callbacks. web3.eth.sendTransaction has a full chain to track events. As well, web3 has event emitters which allows for waterfall promise model. So web3.eth.sendTransaction can run without waiting for a transaction hash to be returned and inputted, but with aionweb3, aionweb3.eth.sendTransaction requires waiting for the transaction hash before running.

In web3:


web3.eth.sendTransaction(transactionObject)
.on(‘transactionHash’, function(hash){
...
})

In aionweb3:

aionweb3.eth.sendTransaction(transactionObject [, callback])

Working with cutting edge libraries

One problem that we came across early on was with signing and sending transactions. The RLP library, which is part of the aionweb3 library, had a bug with signing and sending transactions using private keys. Fortunately, the aion-keystore library unblocked us and the issue will be totally fixed when aionweb3 1.0 comes out.

Difficulty of making message stream between DApp and extension

It was initially quite difficult to listen to messages that were being sent from DApps to the extension. As well as sending replies to those DApps. Chrome’s window.postMessage methods were used to listen and send messages from browser tabs to other browser tabs, or to and from the singleton process of the browser. We had to learn how this works and then figure out how to work around Chrome’s API restrictions.

For example: the run time API cannot be directly accessed from a content script. We needed to use window.sendMessage and window.eventListener functions to do this, and eventually the singleton process of the browser would listen and pass on data to the extension.

Development environment set up such that the content script gets injected into webpage programmatically

Chrome has two ways to inject a content script:

  1. Specify in manifest.json
  2. Inject programmatically on events (document.start for example)

By running our dev environment, we needed to make sure that it got injected. We needed to host a bundled content script by figuring out the path of bundled content script on the server, then use the text of the bundled content script as injection on the DApp. Without doing this, we wouldn’t be able to hot reload the extension.

if (process.env.NODE_ENV === ‘production’) {
const url = extension.extension.getURL(‘js/contentScript.bundle.js’);
injectScript(url, ‘body’);
} else {
injectScript(‘https://localhost:3000/js/contentScript.bundle.js', ‘body’);
}

Difficulty building a tool that was required by DApp developers without example DApps (since they needed the tool first)

Classic chicken and egg problem. AIWA supports AIP-4 tokens but only a reference specification exists; there aren’t AIP-4 tokens out in the wild yet. To get around this, we modified the reference AIP-4 smart contract to make it as general as possible. During testing, some bugs in the smart contract were identified but it was eventually updated as well. Once we had functionality built around the reference implementation, we were able to provide development versions of AIWA to other developers who were working on AIP-4 tokens. After this, we collected their feedback and fixed numerous issues that were pointed out, as well as rearchitected some of the way that AIWA works based on their requirements.

Though there were many challenges, the successes vastly outweighed them.

Satisfaction of going from XD designs to a working tool

AIWA started as an idea in our heads and was quickly hashed out in Adobe XD. We wanted to focus heavily on the UI/UX and make it as good as possible from the beginning, but we knew that it would be a challenge to implement it. Seeing individual parts of it come together over time, like the drop down menus is very satisfying.

Building relationships with Aion team and DApp developers

The most satisfying thing was building the relationship with the Aion team and DApp developers. We worked closely with Aion’s product managers and developers and they were instrumental in our success. They provided technical assistance as well as marketing guidance.

They also put us in touch with some of their partners who were building DApps and infrastructure relating to Aion Network. Working closely with these developers was rewarding because we could see that our efforts were helping them build useful DApps and tools, and that their feedback helped shape AIWA to be what it is today.

AIWA is now available on the Chrome Store. For more information about AIWA, visit getaiwa.com

BlockX Labs builds developer tools for blockchain ecosystems. We also focus on building solutions for private/public blockchains. More info @ www.blockxlabs.com