New achitecture approach for Deltachat (Desktop)

Feature Proposal
1

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:
dc-html-software-design

2

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)
2 Likes
3

+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

3 Likes
4

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.
3 Likes
5

Any consideration to use vite and preact?
Migration from react is seamless and hmr is very fast and convenient for development…

6

did you consider absurd-sql for the rewrite to browser?

7

let me make one thing clear we are not rewriting core in javascript. Absolutely not. the whole point of core is that we only have to write the “business logic stuff” once for all 3 platforms. When web assembly advances (threads and access to raw TCP sockets are two things not solved yet AFAIK) we might port core to it, maybe then absurd-sql could come in handy, provided it is faster than sqlite compiled to wasm and not too hard to integrate.

It makes no sense rewriting core in js, if you want it to run completely in the browser the path that you should take is compiling it to wasm, that way the code bases could stay in sync, but you’d still have to proxy websocket to tcp that you can speak IMAP & SMTP.

1 Like
8

Did you see tauri yet ?

9

yeah migrating to tauri or so is the idea, fun-fact: dc40 already uses tauri meanwhile.

1 Like