What would be needed for a Standalone web version without a server component?

Feature Proposal
1

We recently made a web version of the delta chat desktop UI. [blog post coming soon]
The downside to this is, that it still needs a local server component to run chatmail core (formely known as deltachat-core-rust).

Ideally we would be able to not need to this server component and run delta chat as fully standalone web app or browser plugin.

Our core library is written in rust and rust a popular source language for compiling to webassembly, so why not “just” compile core to wasm?
Unfortunately it is not quite that simple. Here is a (non complete) list of what we would need to make this possible:

  • threading in wasm, we use tokio as async runtime, which only has limited wasm support.
  • performant sqlite database in the browser
  • Since browsers don’t have an API for raw TCP sockets (which is the basis of the email protocls IMAP and SMTP) we would need a proxy to websocket
  • Blobs (basically files like avatars and attachments)
    • could be stored with filesystem api or inside of IndexedDB
  • OpenSSL
    • probably hell to compile to wasm, but we don’t really need it when we trust the proxy: email server <-TLS IMAP/SMTP -> proxy <- TLS websocket -> browser <-> DC Web

We already have:

  • web UI that is independent from electron
  • an API that can be used in the browser → jsonrpc api

Let’s use this thread to share progress and discuss ideas for making a standalone version of delta chat web.

3 Likes
2

Is OpenSSL needed for something other than establishing secure connection to the email server? If so then indeed it looks like it’s not needed.

3

OpenSSL is only used if you disable “strict TLS”. We only don’t throw it away because of the servers that use RSA 1024 keys: Autoconfiguration fails with nauta (invalid certificate: InvalidSignatureForPublicKey) · Issue #1007 · chatmail/core · GitHub
Normally Rustls is used.
OpenSSL is the least of a problem, can be completely omitted for WASM builds if needed.

2 Likes
4

The biggest problem with running applications in the browser is reliable storage. What I can tell from my experiences (~4 years ago) is that even if you request the explicit storage permission of the browser, so the user has to explicitly allow and click “OK”, the storage can be deleted randomly.

Maybe the browsers today are more polite but relying on the assumption that the user’s storage is save caused creditability-loss and stopping my project.

So, if you really want to trust the browser to store your data, and put efforts into this, I would suggest to analyze the code of each mainstream open source browser that is responsible for storing future user data.

Total data-loss is not acceptable for users.

1 Like
5

There is a proposal though GitHub - WICG/direct-sockets: Direct Sockets API for the web platform.

1 Like