Dether Development Update #1

What we learned from your feedback, and what’s in the works

This post will be the first in a series of development updates designed to share our progress and our vision for the next steps with our community.

After the release of the alpha version of the app, we were able to collect a lot of user feedback — coupled with our customer interviews and feedback during our meetups and travels, we reviewed every UX aspect of the app.

Five months have passed since we released the alpha. Our goal was to introduce the project and show that a Dapp could be accessible by all, and that we could reconcile UI/UX and issues related to Ethereum (private key management, transactions, gas, etc.)

A UX redesign has been carried out, and, aware that a mainnet version needs to have irreproachable code, the app has been totally recoded from scratch. The dev team is now composed of 6 people with different profiles working on different elements of the project to be able to start releasing it on main net at the end of March.

A look at what’s changed
Let’s see in detail where we are and what has changed since the alpha:

The dashboard: When we coded the alpha, we wanted something simple, where all of your information was at the tip of your fingers. This is suitable for a single-function app. However, as soon as we integrate our token, other ERC20, or other features, it could become problematic. That’s why we decided to change our architecture. This way, you have a contextual overview about every aspect of the project.

We plan to maintain our vision of PWA first — we are strong believers that the PWAs will continue growing and soon be a standard. Despite this, for convenience purposes, we have already started to port the react code we have on react-native, so we will soon be able to deploy the Dether app in the App store. We’ve used React 16, redux, and StoryBook, and we’ve share styled components with the React-Native app.

Sibling Dapp

A lot of feedback we had was about latency: as soon as you have more than 50 sellers to download, the app became very slow. And as we target unbanked populations, we need to be very low 3G compatible.That’s why we’ve decided to change the architecture. On the alpha, we were fetching the data directly through web3, formatting it in js, and displaying it only the first time the user connected to the app. However, this proved to be a long and heavy process.

That’s why we decided to switch to a Sibling Dapp type architecture. Now, only the transaction/writing portion goes from the device to an Ethereum node, while all the read functionality comes from a NoSql database. A modification to the smart contract emits an event, which is “seen” by our back-end built with koa.js, which then updates the database. This way, we reduce data consumption, and have an acceptable delay and time reaction, even with a low 3G connection

Solidity and Ethereum provider wallets

For the smart contract aspect, we’ve kept our modular approach with an interface and different storage, one for the seller data and their ETH, one for DTH, and one for merchants. This way, we can update the interface by keeping the same storage.

Another reason we’ve changed our heavy infrastructure was that we were using 3 different lib to interact with ethereum. Web3.js as provider, eth-lightwallet.js for wallet and truffle-contract for interacting with the contract. We have switched to ethers.js to handle all these different aspects: etherts.js allows you to create and manage a wallet, have a provider, and manage contracts in one library.

We are just a few weeks away before completing a big step in our project. It will be our first main net release after more than a year of work. We want to be careful to take the highest precautions, as there are both legal and security aspects to take into consideration.

Because the application functions on a local level, our roll-out won’t necessarily happen simultaneously worldwide — instead, we will most likely carry out country-wide releases, taking into consideration the legal factors unique to each region, and adapting our release strategy accordingly.

In order to do so, we are following a precise strategy, as many exciting challenges await us on the road to adoption.

We will explain more about our deployment strategy in an upcoming post!

Stay tuned!