Improved Linux Install and Overall Experience

The current Linux install experience and instructions are a little bit lacking. We give users a script which tries to setup a docker environment for running the browser service and a local api endpoint.

There’s a routes to go towards improving this experience.

1. Improve the Docker Experience a. Issues with the script – it seems like the biggest issue is in password selection. We could just try to auto-select a password, and then pass this along to xdg-open – or output it after startup. b. Other script issues? Sometimes blockstack-api fails to start, I believe because the registrar lock isn’t getting cleaned up. c. The images are huge. Like 1GB. d. Docker is a pain to set up on a bunch of different platforms

2. Ship a Virtualbox image or QEMU image a. We need to still perform the setup – so the password is still an issue. b. Would users access the browser from inside the VM? c. How do we automate building these images?

3. Recommend pip plus a package for the browser? a. pip works fine, but there’s still an issue of configuration and setup. b. would also need to solve the problem of packaging the browser – we have an apt package, which would work, but again, that’s something that needs to be attended to. c. alternative to pip is also just to do a deb package but with the full virtualenv, dhvenv I think is the route people go here.

4. An orchestration app like what macOS has now.

[jackzampolin]

So after meeting with @jcnelson and @kantai we decided to take a 2 pronged path: improve the docker install and document the installation from source. The docker install has the primary downside of docker being difficult to install. The from source option has the the primary downside of requiring full python (2.7) and nodejs (6.9) dev environments setup.

@jcnelson will document the from source install @jackzampolin will make the following changes to the launcher script:

• Add better error messages and eliminate silent failures
• Change install path from ~/.blockstack to ~/.blockstack-browser to avoid messing up CLI users
• Remove anything stored in the /tmp directory on start or stop
• Switch to using blockstack ping to generate client.ini on first run then use the API pass as the wallet password when running create-wallet
• Eliminate the need to input password when starting (use the client.ini API pass for this)
• Improve usage documentation to fully document all available commands.

[jcnelson]

Here are my issues right now:

• Multiple unreliable containers. Can we please try to consolidate all Blockstack processes into one container? I want the stop directive to kill everything, and I want start to always work correctly. Right now, sometimes the stop directive has a tendency to leave some containers running. This prevents the subsequent start directive from working correctly.

• Unreliable clean-up. Sometimes some registrar state gets leaked to the host’s /tmp directory, which prevents start from working after stop.

• Shared ownership of ~/.blockstack. Some users have a ~/.blockstack directory already, since they were CLI users. We need to make sure the Blockstack Browser script has its own, separate ~/.blockstack directory (let’s say ~/.blockstack-browser), so they don’t accidentally erase their old wallets.

• Unreliable Protocol-Handling. There are lots of corner cases with XDG tools not handling blockstack: URIs correctly, and us not being able to figure out why.

• User-generated Core Password. Users get confused as to why they need to know two passwords (12-word phrase and this one). Can we generate this automatically for them?

• Docker is hard to install. This isn’t to say that Virtualbox is easy. But, if you look at our forum, you’ll see this is a pain point for users. Docker does not have a GUI, and does not ship with all major distros. The installation instructions require users to drop into the CLI, add 3rd party package repositories, install Docker, and then add themselves to the right user group. The exact opposite is true for Virtualbox–it has a GUI, it ships with all distros, and no further work is required to use it once the package manager installs it. It also has a generic Linux installer that puts it into /opt that works with anything newer than RHEL5 and ships with glibc.

I am of the opinion that a full VM makes these problems easier to address, but I don’t care too much either way as long as they are addressed.