On ElectrumSV, mobile and UI
One of the things I recently explored was the possibility that ElectrumSV could use a framework like Ionic or Flutter to move forward. The following article summarises my position on the likely path forward.
The main goal of this article is to summarise my current stance on this subject, so I hopefully have a clear picture to refer to as we get time to work on it. Having reread some of my past articles I am not so sure they have succeeded in that sense. Secondary goals are to solicit feedback. But there's a lot of work to do before we get to the point we are ready for this.
On Ionic
The core problem that ElectrumSV has is that it is written in Python. We had always planned to decouple the backend wallet server from the user interface, and have the user interface written in some form of Javascript and HTML. But let's consider one of the end goals, an iOS application. From what I understand, iOS is very limiting in terms of the application. So the idea that we might bundle the backend wallet server in the Ionic application, and run it in the background appear to be largely infeasible. Indeed doing so in any Android application might also be problematic.
Ionic also deploys to desktop targets, like MacOS and Windows. And in those cases, it is likely that we could get away with bundling the wallet server and running it in the background. But if it doesn't work for mobile, then this isn't a solution that works across the board.
So the conclusion is that we might very well consider Ionic for desktop, but for mobile we might have to come up with a different solution, perhaps even per-platform solutions.
On Electron Cash's mobile applications
Electron Cash has mobile applications for both iOS and Android.
- The Android application is based on a framework called chaquopy, that allows mixing Python and Java. It implements a custom Android-specific user interface in the Kotlin java-related language.
- The iOS application is based on.. well the stuff you use on iOS. It implements a custom iOS specific user interface in Python.
What both of these do, is embed the main Python-based wallet code, and add a platform-specific user interface in front of it. This is in-process wallet support, with a user interface. It requires extra per-platform work both for development, and maintenance. The appeal of an approach like Ionic or Flutter, is that the user interface and code should largely be cross-platform.
On changing direction
The ideal of being able to bundle and run the Python-based backend wallet server and have a completely cross-platform user interface working on desktop, mobile and the web, is probably infeasible. So, what is the alternative?
I think there's a compelling argument for sticking with Ionic, and using React on the desktop, mobile and web. We can start with it using a remote wallet server you run yourself, just like the way we plan the web-interface and desktop interface to work. And as we get more time we might flesh out Javascript wallet backend code to run directly on the mobile applications. I suspect the largest piece of work will be the code for the secure key storage on the devices, but that's just speculating.
On Windows builds
In the past, ElectrumSV (and Electrum Core and Electron Cash) have had problems with malware because the packaging tool we all use is also used by malware. This packaging tool is PyInstaller. For a while we solved the problem, as someone involved with Electron Cash came up with some code that changed the signature of the PyInstaller startup code. But it appears that every Windows build we make now gets flagged again in a range of different malware detection products.
I've spent a day prototyping a new custom Windows build, and it works and runs, but one problem.. it's over 200 megabytes in size. It turns out that PyInstaller has an analysis pass that strips out the unused parts, and restructures things so that the builds it makes with the same inputs come out to lower than a quarter of the size (and lower than one sixth compressed). Reproducing that code would be prohibitive.
The next step for the prototype is to try and invoke PyInstaller, and have it package the build, then see it it's feasible to replace it's startup executable with an generic embedded Python interpreter that uses our icon and invokes our replacement startup script.
The theory is that in the short term before we switch to very likely Electron-based Ionic wallet releases, this provides us with a way to do Windows releases that won't be classified as malware. If our code signing certificate comes through, this will mean that we should also be able to distribute a signed MSIX installer via the Windows store. For those that don't want to use the Windows store, we'll likely provide a zipped archive they can extract and run, and perhaps a signed downloadable installer.
And beyond that, we should be able to take the new build process and bundle it in the Electron-based release and run it alongside the Ionic UI which would use it as a local wallet server.
Summing up
So the loose plan for the specific topic of the future direction of release packaging for ElectrumSV currently looks the following:
- Decouple from PyInstaller's startup executable to solve the malware false positive problem hopefully once and for all. The Windows experience should be more polished and professional.
- Look to start prototyping an Ionic-based cross-platform UI.
- Get a wallet client APK working for Android as a proof of concept based on Ionic.
- Get Windows and MacOS Electron-based releases working as a proof of concept based on Ionic.
- Work out what is involved in accessing secure key stores on both Android and iOS platforms.
But as usual, we have a lot of things to work on and it gets done slowly. A lot of the things we have planned have been backlogged. The main focus is making sure the wallet as-is continues to work as reliably as possible.
-- rt12
