New achitecture approach for Deltachat (Desktop)

These days I tested the first time deltachat deskop. This app is very nice but could be
more flexible and much more lightweight.

So I want to propose a new software design approach from industrial automation technology we are using for years now with great success. Maybe this could be
useful and a good template for a next (new) deltachat software.
I would think this could be build quickly on top of cmd line tool or maybe in collaboration with a python cmd line app.

This is my proposal:

We plan to remove the requirement from electron so that we can use the ui in the browser and connect to the backend over websocket.
Then after that step we plan to move away from nodejs and code the backend in rust.
Though there are two parts to the backend:

Also for reference there are 2 other active desktop client projects:

  • dc40 (still uses electron for now to show the window, but both frontend(compiled to wasm) and backend are written in rust and communicate using a state-store that is generated by the backend and displayed by the frontend)
  • kdeltachat (native deltachat client written with Qt and KDE’s Kirigami framwork)

+1 for an real cmd line app
I would like to use it so I can use bash scripts to script deltachat, so for example sending out a message to a contact. (encrypted, otherwise I could just use sendmail I guess…)
Thought TUI would also be interesting, @adb experimented in that area: GitHub - adbenitez/deltachat-cursed: [WIP] Cursed Delta, a lightweight Delta Chat client


As a supplement some background information related to my proposal:

  • We are using this design for 15 years now in production environment.
  • The whole application is based on standard installation of python without any extension.
  • It shows very reliable operation, excellent performance and quick user response.
  • There is no java script in pages. We are using simple html with css to build the ui and data pages.
  • Pages are build dynamically related to data which needs to be presented.
  • Quick refresh is done by some kind of long polling requests.
    We are not using web sockets, but standard http requests
  • Internal web server has direct access to internal data structures of the application for quick operation.
1 Like