In Fedora 32, PyQt4 is no longer shipped with python2, so I failed to get most recent tags of Armory to build.
Moving away from both py2 and qt4. The dev branch as you've found out runs on py3. I have not migrated to qt5 yet, that will come soon.
but state showed disconnected
A quick history on the architectural changes:
- Prior to 0.94, all of Armory C++ code was made available as a shared library to Python, using SWIG.
- The next step was to isolate the blockchain service (ArmoryDB) from the rest of the wallet. The client (ArmoryQt/Python) talked to the blockchain server (ArmoryDB/C++) over a socket, using the FCGI protocol (some older protocol from the CGI days, meant to sit behind a HTTP daemon). This connection was not encrypted. ArmoryQt would spawn the DB on its own, connect to it locally and do its thing. Connecting the client to a remote ArmoryDB was not recommended, due to the lack of encryption. Savvy users would typically go around that limitation by SSH'ing into their remote system.
- The current iteration (in the dev branch) uses WebSockets (via LWS). LWS is a robust lib that can handle exposure to the WAN. It can also be paired with a load balancing front (nginx is easy to setup for one) and/or operated behind a cloud host (cloudflare/linode and the likes). The connection has its own AEAD layer added (chacha20poly1305). You can enable TLS in LWS at your own discretion but it isn't on by default and will require setting a few flags in the code and rebuilding ArmoryDB. Since the connection between client and server is now encrypted and authenticated, you need to share keys between the 2 before a connection can be successfully established. This is where your setup is failing atm. More on this at the end.
- SWIG has also been dropped. It didn't mesh well with py3 and imposed annoying restrictions on the build system (particularly with OSX). I didn't find a satisfactory replacement for SWIG so I ended up writing what amounts to a RPC API (CppBridge). This new process talks to ArmoryDB as well as handles wallets and all the crypto. The Python client has been relegated to a dumb interface: all it does is render GUI, the heavy lifting is done in CppBridge. CppBridge will also automate ArmoryDB (this isn't implemented yet).
- CppBridge talks to ArmoryQt through a socket as well. This socket is not yet encrypted, I am currently working on this. There is no fitting chacha20poly1305 Python package out there so I am in the process of creating one myself using CFFI. This connection will be authenticated as well, so it will too require a key share. ArmoryQt automates CppBridge.
-----------------------------------------
Regarding key shares, the default mode for the AEAD channels is 2-way (client authenticates server, server authenticates client). There is a 1-way mode as well (client authenticates server, server does not authenticate client). This mode is only available for ArmoryDB. It needs to be started with --public, and so does the client (1-way clients can't speak to 2-way servers, 2-way clients can't speak to 1-way servers).
In your specific case, to get the dev branch running you would have to share the ArmoryDB's key with CppBridge and vice versa. Assuming you use a 1-way setup, only CppBridge (the client) needs to know of ArmoryDB's key (the server). The keys are stored in dedicated key stores. CppBridge looks for its keys in clients.peers. ArmoryDB looks for them in server.peers. Both these files (when used) are found in your datadir (~/.armory). Ephemeral setups ignore these files. These are used for on the fly key shares when one process automates the other. Since you are running ArmoryDB manually (no other way to do this atm), you are using static keys, hence the key stores.
You can view the content of keys stores and manipulate them with the help of a plain command line tool found in /cppForSwig/KeyManager. I have yet to write any documentation for this tool, but the code file is small and fairly easy to parse:
https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/KeyManager.cppCurrently, CppBridge is hardcoded to accept any server key in a 1-way setup. This means you do not need to actually setup a manual key share, but instead you would need to run both CppBridge and ArmoryDB with --public. ArmoryQt should already pass it this argument to CppBridge, so chances are you are missing --public when running ArmoryDB. In the future I'll remove this shortcut. By then CppBridge will have the code to automate ArmoryDB and will setup an ephemeral key share to secure the socket. It will do the same with the socket to ArmoryQt. The key share process will be for people looking to access a DB remotely and/or allow access to select known peers (or open it up to the public).
