With the release of v1.6, Decred massively expanded its feature set. Decred DEX is ready for action. Lightning Network and privacy are now supported by Decrediton. But it seems that with every new successful product launch, users have one more configuration file, one more command prompt, and a slew of new support requests.
If you're only going to use Decrediton, you've got it pretty good. Windows users get a GUI installer and a shortcut in the Start Menu and on the desktop. No command prompts needed. But as soon as we add another piece of software to the mix, things get complicated. Who should start and stop dcrd? Do they share a dcrwallet? If they do share a node or wallet, how are configuration settings coordinated?
And with every new project release, the possible combinations of software grow exponentially, and the configuration complexity with it. It's a wholly unsustainable state of affairs if we expect Decred to gain wider adoption.
My first question is this. What if there was a single GUI installer for all of the Decred programs?
Yes, we do have dcrinstall. That gets us part way there. But it's not a GUI installer and it doesn't install menu icons. And the user still needs to manually run dcrd and dcrwallet to use anything except Decrediton.
I think I have to agree with @davecgh, who recently said,
A graphical installer / setup wizard is something that would help quite a bit with the UX, imo.
We need a full-featured GUI installer. But even that doesn't solve our problems. We still don't know who's in charge of configuring and starting a shared node and possibly a shared wallet. Right now, barring more complex solutions, most users just do this manually. But as @jrick said recently,
dcrd should be run as a background service, not attached to a tty
So for maximum usability, we really need to install the core Decred software as a system service. We'll also need to keep it up-to-date, running, and ready to use.
OK. So let's say you've got your GUI installer and your system service is installed and configured to start with OS, and there are icons in the start menu. To prevent issues with duplicate dcrd instances, when you open Decrediton, you'll need to choose the advanced configuration and in the field for RPC address, enter ... WAIT! Isn't our goal to get rid of complex user configuration? It appears we still have a problem of managing configuration compatibility. And how do I stop or reconfigure the node? If the instructions start with "In your Windows search box, type in 'services'", or "Open your favorite text editor" , then we have again failed to do our job. Also, how many icons are there in my start menu for Decred now? Geesh.
This leads me to my second question. Wouldn't it be nice if there was a Decred application manager to update and launch Decred software, sort of like Steam does for games?
Introducing Decred Eco. Eco aims to be the one-stop, CLI-free, config-file-free Decred application manager. A version manager for core components (dcrd, dcrwallet, dcrlnd), and on-demand installation, auto-configuration, and launching of Decred apps, starting with Decrediton and DEX.
Eco itself is installed with a GUI installer, and the backend component of Eco runs as an auto-start system service that, among other tasks, keeps the blockchain synced.
The frontend is a GUI that can instruct the backend service to install and launch Decred apps. There is also one "built-in app", dcrctl+, so you can call dcrctl commands from the same window. No command lines.
-
Not you. Eco has almost zero levers, and if you're reading this proposal, you are most likely already comfortable with configuring Decred software. But we're a miniscule fraction of the future Decred userbase. Noobs and technophobes need love too.
-
Everyone, including you, because we all need simple sometimes. Eco distills basic system configuration down to a password and a click.
-
Developers. Without even using any apps, Eco can be used as a tool to keep the core Decred software up-to-date, and to retrieve system status information. You don't even need to use the GUI. And the eco package exports all of the backend's functionality, so Go programs can interact directly. Clients for other languages are possible too.
- Go-based GUI
- Auto-updating version manager for core Decred software
- Auto-updating application manager for Decred applications
- Blockchain always synced
- Built-in dcrctl interface
Decred Eco is actually 3 programs; the installer, the system service, and the application manager GUI. Everything is written in Go.
The installer just installs the service and GUI components and registers the system service. There is a small GUI window to display installation progress, but installation is nearly instantaneous. The Eco Installer does not install the core Decred software (dcrd, dcrwallet...) or an apps, just the Eco service and application manager software. The latest releases of everything else are installed the first time the user logs into the application manager, with installation and sync status displayed to the user there.
I considered writing separate installers for each OS, using established OS-specific techniques, e.g. .deb for Debian, Inno Setup for Windows. The problem with that approach is that Linux package managers want to install everything system-wide. They don't directly support user installation, and while there are ways to make it work, by the time you're done, you're essentially left with a shell script and a bunch of unnecessary boilerplate.
Instead, since systemd and the standard user-specific installation paths are mostly standardized on Linux, we can just write an installer to move files and register the service that is completely Linux cross-compatible.
In order to package Eco, there's a packaging system that compresses the 3 Eco programs and static files and compiles the archive directly into the installer, resulting in a single-file offline installer.
It follows naturally that the same approach can work for Windows by simply separating OS-specific filesystem and service code using +build directives.
This component is installed and run as a auto-start system service. On Windows, this is a standard system service. For Linux, we use a systemd service configured for the --user. The service is installed and registered by the Eco installer.
The service does all the system stuff, including updating software and launching applications. To the greatest extent possible, both core software and applications are run in isolated environments, with custom app directories and server addresses. This is important to avoid any conflicts with non-Eco-controlled Decred software. For developers, this means that Eco shouldn't interfere with any of your existing development activities, but it also means that the blockchain will be stored twice.
The service runs a small server (Unix socket on *nix, TCP on Windows) that other programs can interact with to query the system status, launch Decred apps, and proxy dcrctl calls. Initially, the Eco Application Manager will be the only client, but other apps could use Eco's tools to get, for example, the status and address of the dcrwallet or dcrd JSON API. As opposed to a server/client model, interactions with the service are abstracted through exported functions in the eco package.
In discussion leading up to publishing this proposal, there was some question as to the decision to run a single service that controls all daemons rather than running the daemons as individual services. There would be obvious differences in the code structure and the GUI would have to take on some of the systems-level tasks that the Eco service handles now, but it would not be a massive undertaking to change. Some arguments are that using separate services provides more granular control over permissions/security, leverages the OS tools for e.g. service auto-restart on crash, and crashes are isolated. While I do believe these issues are manageable with a single-service approach, it does carry complexity.
One possible feature I was hoping to implement is live log feeds, and the Eco system service is already coded to allow subscribers to those feeds. Live log feeds would be substantially more difficult to implement with separate services.
It's really an implementation detail and could be changed at any time before release. I bring it up here only for discussion, but I may update the prop before voting, based on feedback.
The Eco Application Manager, or just Eco from the user's perspective, is a GUI for installing and launching Decred apps.
In theory, people may find utility in installing Eco just for the system service and features, but my hope is that the Eco GUI becomes the primary way that (especially non-techie) cred-heads use to access the Decred ecosystem.
Simple applications can also be coded directly into the application manager as "built-in" apps. As a demo of a built-in app, Eco comes with dcrctl+, a GUI interface for querying dcrwallet's or dcrd's JSON API.
-
There is an entire hidden ecosystem of disparate Decred tools that have value, but no graphical interface. For example, @matheusd's split ticket mathcher and @jzbz's cold wallet setup script. Eco could absorb those projects and give them a proper home. Eco can also handle complex configuration tasks like setting up cspp.
-
Certain atomic swap contract funds would be at risk if the DEX client goes offline for a long time after swapping but before redeeming. The DEX client could go offline if 1) the user restarts their machine, but not the DEX client, 2) Windows militantly installs updates, or 3) there is a power outage. Since Eco runs as a system service on startup, Eco could run the DEX client on startup, perhaps in some kind of recovery mode. This would take some coordination with the dcrdex project.
-
The same reasoning from problem 2 applies to LN channels, which rely on a nearly identical contract as an atomic swap. On startup, Eco can run a program to monitor existing channels.
-
Go's support for GUI programming is a known weak area. In the process of writing Eco, I lightly evaluated 4 or 5 options and deeply evaluated two before settling on fyne. And while none of them provide the anything near the power of established tools like Qt or HTML/CSS. What I liked about fyne is the way everything is interfaced out, such that you don't need to use their widgets at all, or you can embed and modify as needed. As part of getting fyne to look more modern, I've developed a custom widget and layout manager called
Element, in the eco/ui package, that adds a lot of familiar features, for example...
- Absolute and relative positioning
- Inline and block positioning
- Custom margins and padding
- Borders and border radius
- Custom background colors
- Flex-style layouts
and a bunch of other widgets and tools for GUI development. The ui library is already structured for importing and used in both the GUI installer and the application manager. While ui is still a work in progress, I believe that ui on top of fyne is a partial solution for modern GUIs in Go.
I am aware that stakeholders recently made an USD 8000 investment in sponsorship of the Gio project, and that I chose not to use that package. I have no problems with Gio, but it did not make the cut during my early Go GUI research. I wouldn't be against re-evaluating, but all other things equal, I would venture that the USD 8000 investment is not worth rewriting Eco with another library.
A working prototype for Linux is done, and Windows is in progress. There are lots of issues, and some features to round out. The itemized list below should cover the vast majority of development activities needed before a release.
- Test, test, test
- General improvements to the installation process
- Lazy load apps
- Install new releases automagically
- Documentation, both code and public
- dcrctl+ features: history, links, autocomplete
The fyne Go-based GUI library being used has some limitations and some issues with concurrency. Solutions to these issues exists on fyne's development branch, but are not anticipated to be in master or a release until later this month. I've opened up a conversation with the fyne developers, and have also submitted my first contribution to their project. I expect to continue collaborating with them.
- Network peer explorer, which could be another built-in app. Could even try to geo-locate IPs and map them
- Live log viewer to display raw node and wallet output
- A simple point-of-sale app to allow users to generate addresses, invoices, QR codes, etc. to accept Decred payments
USD 59,800 includes
- 15k for work completed. Conceptualization, 10k+ lines of new code, UI design
- 28 full-time equivalent weeks (FTE evaluated at $40/hr output level) of development includes
- 8 FTE weeks for code refactoring, documentation, and testing.
- 4 FTE weeks for Windows integration
- 6 FTE weeks for continued app integration, including collaborative efforts and dcrctl+ development
- 10 FTE weeks for continued development, support, bug chasing, marketing
This will be a part-time endeavour for me, as I dedicate the majority of my time to DEX. But @JoeGruffins is gonna pitch in too, and as always, contributions from anybody are welcome and encouraged. A release is anticipated in 9 - 12 months, though with additional dev support, that could happen more quickly.