Web client possible?

is it possible to get a web client in the future?
I’m behind a firewall so connecting the IMAP Port with the client is not possible.
What are your option to this?


Hi, @jakob1 welcome to our community :wave:
having a web client the way you describe is possible, but it will mean you will have to trust a central server that will host your chats, etc.

1 Like

Hi @adbenitez!
Thank you.
OK, I understand. So selfhosted would be an option or a plugin for eg nextcloud.com?

1 Like

can you use a proxy?

1 Like

I like that idea :slight_smile:

However I’m afraid it will go down as just another idea for a feature. The problem is, who would develop it and what would be the motivation? You could post it somewhere where nextcloud developers would notice it, but they probably also have their hands full. But maybe you’ll get lucky and someone wants that feature and develops it.

Another idea would be to have a server that only relays edge to edge encrypted information. Your mail server would have to support that and I don’t think there is a single one that has this kind of functionality. At least I have never heard about that before. But it is technically feasible :slight_smile:

1 Like

Digitalocean + RoundCube + mailvelope?

How To Install Your Own Webmail Client with Roundcube on Ubuntu 16.04 | DigitalOcean


Protonmail as a service seems unlikely

Maybe https://posteo.de has AutoCrypt in their webmail?

Would you expound on that a bit further?


Would you expound on that a bit further?

Hello, well as I said the mail server would have to support the feature in some way.

  1. It could have a second key which does not allow decryption of your mails but does allow fetching the mail data in encrypted form.

  2. Hence a webmail server would be able to fetch your encrypted mails if you allow it by giving it the fetch-only key.

  3. Then locally per Javascript for example (or a browser extension) you could decrypt with a mail decryption key. That step would happen without the webmail server knowing anything about it. (The Javascript file needs to not be hosted by the webmail server though, that would be a critical security flaw. Although another script could maybe validate that script file, hmm…)


1 Like

@Lexi @eatanimals

Is your vision dissimilar to


Dovecoat is a flavor of IMAP.

The Mail crypt plugin is used to secure email messages stored in a Dovecot system. Messages are encrypted before written to storage and decrypted after reading. Both operations are transparent to the user.

In case of unauthorized access to the storage backend, the messages will, without access to the decryption keys, be unreadable to the offending party.

Therefore webmail client agnostic?


Hi zgzgng, I only read the text that you quoted and it does read like it’s kinda similar but I think the authors wanted to have an additional security feature. While what I described was not a security feature in itself. Dovecoat sounds like in the case of the server being cracked it has another security feature: The mails are encrypted. What we want would be to purposely allow that step. That would be a hack of the feature, but maybe it’d work out. We’d let the webmail server “crack into” the mail server on purpose, but since Dovecoat encrypts all mails (if I understand correctly) it wouldn’t be able to read the contents. Encryption of the mails could then be done by Javascript (as I said precautions must be taken to ensure the webmail server can’t access the mails decrypted content through this Javascript code).

By the way, if mails are pgp encrypted they are already end to end encrypted, so no additional feature is needed. You could use that right now. You’d just need the Javascript mechanism for decrypting. There’s probably a library for that already available. However few people use pgp so most mails’ content would get leaked to the webmail server.

However, why not just use a native client? What do you all like about webclients? The only convenient feature that comes to mind is that you could use it everywhere. However most computers have Thunderbird installed as well or can just install it, right? So maybe it’d be better to code a feature for a native client that does what you want. Or use an Android virtual machine and use the DeltaChat Android App :stuck_out_tongue: Wait, hasn’t the DeltaChat team already written a native client? Yeah Issues · deltachat/deltachat-desktop · GitHub
Guess it’s not available for Windows. In that case you should switch to GNU+Linux anyway :stuck_out_tongue:

1 Like

Our desktop client is powered by nodejs and electron and it does run on gnulinux, macos and windows.
-> get.delta.chat


Thanks Simon. I wonder why people want a hosted version of Deltachat. Would it be possible to convert the electron client to a webextension? That’s probably the best way for the people who don’t want to install anything or can’t.

1 Like

No that’s not possible without webassemby and access to an api to open TCP connections to speak IMAP and SMTP.

1 Like

Even if there is no web client (yet), this might help for now:

  1. People who are on Windows and don’t want to install anything, can use the portable .exe.
  2. People who are on Linux and don’t want to install anything, can use the AppImage.
1 Like

And on mac you can also just run the app without putting it into the application folder. But keep in mind that on mac the data is still stored on the device.

1 Like

I’m wondering, what’d be wrong if a web-client was a simple SPA app (optionally implementing the PWA spec for semi-installable clients)?

1 Like

For me it would be awesome if we could have a web server. I have a NAS at home and I would install it there. Then it would be used for my family and I only. This would avoid having to use a separated desktop app. I do prefer having all my chat programs as pinned tabs in the browser (I already have: emails, mastodon, discord, telegram and slack)

1 Like

Yes it is possible, but it would depend on how it is done. For example:

  • you could have a serverless architecture. That is, having an application without a server or with few resources on the server side.
  • another architecture is unhosted, which is when you run an application in the browser without having an external database.
  • another way is to have a self-hosted architecture, where you have your own infrastructure to your application.

As you can see there are several types of software architecture: unhosted, self-hosted, serverless. There are even hybrid solutions like unhosted+serverless, or self-hosted+serverless, or self-hosted+unhosted.

What I want to point out here would be an unhosted + serverless architecture. That is, the delta-chat can be opened by the user’s own browser. This happens via http calls that communicate in client-side software that is responsible for connecting different email providers, email protocols such as smtp, imap, pop3, jmap, rpop, etc.

An example of a serverless+unhosted architecture is nullboard. You open the application nullboard in the browser, and it communicates with a piece of software called nullboard-agent which is written in C#.

In my opinion this is better than having a desktop on electron. Because from a performance point of view a web page loaded on client side in browser with html, css, js is faster than the same page loaded in electron-js. Because, in electron-js it’s a way to have a browser environment that consumes a lot of ram.

I know this point of view can be controversial, because some developers love Javascript and want to use Javascript for everything. Some developers find it easier to have a Javascript desktop environment, a Javascript cli, a Javascript server, etc.

But my point is: Javascript is not the best language for all use cases. If Javascript is the “best language for all use cases”, then we wouldn’t have things like Python, Prolog, Haskell, Clojure, Java etc.

The general point I want to emphasize here is that there are languages for specific use cases and general use cases, and there are good and bad languages for performance. In the case of javascript, it is not a performative language, despite being a general-purpose language. For example, things like D, Vlang, C, C++, C#, Rust are great languages for performance and specific use cases.

So, the general point is that this topic opens the discussion to a web version of delta-chat, and Javascript can be used for client-side ajax calls, but not server-side.

A good example is nullboard, which uses ajax calls with Javascript and has a nullboard-agent which is a mini server on the client side, something small of 100kb. In that case, you have the best of both worlds: Javascript+C#.

This case is an example that you can create something amazing and performant without lots of dependencies and without having a ram memory full of things like electron-js. What I mean at the end of the day is that everyone wants or expects an application to be fast and a certain amount: perform. The page, website or application does not take long to load, its quick.

One of the general problems of js is its dependencies, and there are easier languages that don’t have many dependencies to create cool stuff like C, C++, D, Vlang, C#, Rust etc.

In my opinion, what is being discussed here can make delta-chat more competitive by being open source with proprietary solutions like Spike, Spark Mail etc. There are libraries for sending and receiving emails in Rust and even in C++ or C# etc.

I wonder if we couldn’t have a delta-chat-agent responsible for sending and receiving emails locally.

I hope I have helped with a general idea of ​​how this would be done, why it should be done.

1 Like

The core is written in rust, so our “server side” / “backend” is not written in javascript.

Optimal would be a native app and not using web-tech because for web technology you need a browser running (be it a standalone chromium in the case of electron or a shared browser in the case of websites). But there is no easy (as easy as html css and js), fast, small and complete UI library that works across all 3 operating systems, maybe Qt and Flutter are the closest solutions to this problem, but we would need someone knowing flutter or qt working on those clients.

that already exist, your basically describing deltachat core. You can build apps on top of it either using it as library from rust, c, and other languages that support using native libraries over cffi or you can use the recently added jsonrpc interface, either over a local web socket connection or over stdio (start server process and communicate via stdin and stdout pipes) GitHub - deltachat/deltachat-core-rust: Delta Chat Rust Core library, used by Android/iOS/desktop apps, bindings and bots 📧

There only needs to be a “web” (or other) UI written on top of it. There were already experiments using flutter, qt, egui, tauri + yew.rs, TUI clients with ncurses and so on.

But I actually think that many people who want a web expect it to work without a native agent that needs to be installed first. just installing deltachat as a browser plugin or just visiting a website like for WhatsApp web.

PS: apps like spike actually store your imap credentials (address and password) on their servers to offer push notifications and other advanced features.

1 Like

with a “delta-chat-agent” it would be possible to port any graphical interface. In fact, there is already something similar to what you mentioned: detal-core-rust. Just confirming what you said: “The core is written in rust, so our “server side” / “backend” is not written in javascript”.

part of what I write has to do with this question: So, does this client have http calls that can be consulted by javascript with ajax?

Wouldn’t it be better to create an installer that downloads a delta-chat-agent? (For most Windows users, just having a “next, next, next installer” pattern is easier to install any software.)

There are things like tiddlywiki that have a browser extension with ajax calls. I wonder if it wouldn’t be possible to have a “delta-chat-extension-browser” as browser extension to send and receive my emails in agent-delta-chat. Is there any browser extension for delta chat?

The main point I want to make with these two observations is that part of any software is somewhere like gnome apps, microsoft store, apple store. People don’t necessarily access websites, usually when they want to install things they access the platform, which is gnome apps, microsoft store etc.

Another point I want to emphasize is the fact of the guided installation, which has always been a standard in Windows. Where you just confirm the installation without reading any terms of use.

There is a serverless/self-hosted proposal on delta-chat here: delta-chat-as-self-hosted-serverless-hosted-twitter-or-reddit, fastest-server-side-implementation-to-self-host-delta-chat

There are open solutions that just plug into storage services. For example, Joplin desktop with sync in google drive/dropbox to notes etc.

Nullboard, version: Joplin desktop with sqlite, Obsdian with “database” in “markdown”.

Joplin server etc.

1 Like

Jsonrpc over websocket is way better than a REST API that is called over javascript ajax, because it is bidirectional, so you get events (new message arrived, chat renamed,…) from the “server” over the same connection as your commands and requests. There is even already an autogenerated typescript client library with an async/await interface.

This was already discussed in the forum in other topics before, the path would be to compile deltachat core to wasm and possibly run it in a service worker, but wasm still misses some features we’d need for that.mainly direct access to TCP sockets (for speaking IMAP and SMTP) and real multi-threading.

Deltachat already uses sqlite as local database and Obsidian & Joplin Desktop are also both Electron apps too (huge ram usage).