Don't Force Your Đapp's UI on me

The above image is from Alchemy, the UI for DAOStack's DAOs.

Disclaimer: in this post I'll criticize Alchemy for some UX and decentralization gaffes, but to be fair I should first state that:

1. Alchemy is an easy target but there are many, many more examples out there and I picked them purely out of convenience and because that's the last UI I interacted with heavily.
2. Alchemy is admittedly in alpha and the team has stated that they are working on solving some of the problems I list below, so it's completely unfair to call them out for that. Regardless, I see these practices enough to consider them worth writing about.

   ---

If you're not familiar with DAOStack, it's a comprehensive expert-level framework of smart contracts for building intricate DAOs (Decentralized Autonomous Organizations). I originally became involved with their stack when deciding on a framework for the Blockada DAO

The above memory crash was a fluke. Some runaway process hung and crashed my tab, as JavaScript apps will do, 16GB of RAM be damned. It's OK, it's just a UI, you might say. Interact with it directly through the blockchain, you cleverly quip.

Sadly, that's not going to work. There are several issues at play that actually make these DAOs quite centralized mechanics-wise and force you to depend on Alchemy.

1. No Source or ABI

DaoStack DAOs are generally deployed through automated migrations and the DaoCreator contract. This means their ABI code isn't made public by default, nor are they verified on Etherscan. In turn, this means you cannot easily access their functions in a raw manner, without a dedicated UI.

This is easy to fix. The developers should either improve the migrations and deployment process in such a way that contracts are programmatically verified, or they should publish the generated source and/or ABI of the final contracts somewhere for all to see and consume, preferably in a common registry like a Github repository.

2. Tech Stack Too Deep

When building for web3, it's worth keeping in mind that not everyone is comfortable with build processes, containers, and complex environments designed to spin up a front end.

In fact, you'll hardly ever find someone who isn't an expert at this willing to go through the painful process of installing NodeJS and accompanying tools just to build a UI.

Actual image of a Hello World page's node_modules folder

Here's what you need in order to deploy Alchemy:

• Docker
• alchemy-server which also needs Postgres
• NodeJS 9 (which means NVM)
• ReactJS (see first image in this post for one of 1000 reasons why this framework is a bad choice)
• Web3js (which also means the infamously awful Node-gyp)
• These other 130 dependencies

That's just for the front end. How many people would be willing to go through all this just to run a UI? How many would be able to debug all the inevitable NPM errors from this list of 130 or so dependencies just to get some buttons to show up that say "Vote Yes" or "Vote No"?

The solution is easy. Build a mini-Alchemy that's ready to go out of the box for each individual DAO deployed with DaoStack. A simple Ethers-JS powered HTML page would do just fine! But this still won't work well because...

3. Subgraph and manual intervention

DaoStack uses a subgraph. Don't get me wrong, what the folks at The Graph are doing is nothing short of amazing. Just see this video:

Subgraphs are basically indexed graph databases populated with synced schematized data harvested from the Ethereum blockchain. In other words, a different, more easily accessible data format for your Đapps. So what's the problem if it enables quick data access and faster rendering?

The problem is that not only is this yet another hosted third party dependency, but it also requires manual intervention from the devs for your DAO to be added to the Alchemy UI - they need to trigger manual indexing in the subgraph so that your DAO gets added and registered. The UI doesn't simply connect to your DAO and then work faster if it's subgraphed - it flat out does not work at all unless subgraphed.

Why use the blockchain at all, then? Why not store it all in a database (it's already using Postgres!) and just save end-states as hashes onto Ethereum whenever a new action is executed? It'd be much cheaper to run the DAOs that way and you could get away with fewer dependencies.

Conclusion

The TL;DR is: make sure your users can interact with your smart contract no matter what. That means:

• make it open source or publish its ABI and deployment address, and let people build their own UIs for it.
• make the original UI brutally simple and rudimentary. A very basic html page with Ethers.js and no build steps (please, enough NodeJS!) or custom databases is more than enough for basic interactions. Look at this voting interface we built for the first NGO-level official blockchain vote in Croatia. Primitive? Yes. Effective? Absolutely. People must be able to simply download your website and run it locally and still successfully interact with your smart contract. Anything else is unacceptable in a decentralized web that's supposed to run everywhere.

When considering good UX, don't trade decentralization for practicality.

I am now working on a simple no-build UI for DaoStack DAOs which will work without subgraphs and can be deployed per DAO. Stay tuned for more info in the coming weeks.