Digitalocean + RoundCube + mailvelope?
How To Install Your Own Webmail Client with Roundcube on Ubuntu 16.04 | DigitalOcean
github.com/mailvelope/mailvelope/issues/535
Protonmail as a service seems unlikely
Reddit.com/r/ProtonMail/comments/8dqk5n/comment/dxpjpbb
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.
It could have a second key which does not allow decryption of your mails but does allow fetching the mail data in encrypted form.
Hence a webmail server would be able to fetch your encrypted mails if you allow it by giving it the fetch-only key.
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…)
Cheers
Is your vision dissimilar to
https://doc.dovecot.org/configuration_manual/mail_crypt_plugin/
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 
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
Cheers
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.
No that’s not possible without webassemby and access to an api to open TCP connections to speak IMAP and SMTP.
Even if there is no web client (yet), this might help for now:
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.
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)?
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)
Yes it is possible, but it would depend on how it is done. For example:
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.
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.
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.
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).
I believe this would be possible in this scenario.
Hello 
,
If you have to install a program anyway, why not DC Desktop?
What would be the advantage of using DC in the browser?
Hi Raiden.
There are easy things that work without wasting RAM. I like everything on the web because it doesn’t require a lot of processing.
I’m trying to help this topic with ipfs. Please see this: https://docs.ipfs.tech/how-to/websites-on-ipfs/single-page-website/#install-ipfs-desktop. There are several advantages, I will list 8 advantages:
performance:
economy
ease of use
security, privacy, anonymity
user experience
independence
What do you think of this idea?
There are several interesting electron-js alternatives here. For example,
In summary, we have the following options:
1. flutter for web/mobile/desktop or
the advantage of flutter is that flutter is used to build cross-platform applications. Because it operates on a single codebase and renders native code on each platform, Flutter engineers can build native-like apps faster and with lower development costs. Flutter apps are compatible with iOS, Android, Windows, macOS and other platforms.
the downsides of Flutter is that it is a relatively new framework and may not have the same level of community support as React Native. This can make it harder for startups to find resources and support for their development projects.
another disadvantage is that you would have to change the frontend or backend or full-stack source code to flutter, which can be bad, because while a newer version is not made, certain features are left out.
ps: Of course users can choose to have an older version with less features compared to the development version.
2. tauri-js or nwjs for desktop or
the advantage of tauri-js and nw-js is that they are alternatives that consume less ram than electron-js.
tauri-js works with webview whereas nw-js will open the given entry point in a browser window. In Electron, the entry point is always a JavaScript script. Instead of providing a URL directly, you manually create a browser window and load an HTML file using the API.
the downside of nw-js, tauri-js is that they take browser resources to work. Despite being alternatives to the electron, they work in a similar way with technically very small differences.
3. self-hosted or
the only advantage of this type of architecture is if you have a personal homeserver or have money to keep the infrastructure of a local server running.
The downside of self-hosted architecture is that a server is required to run 24 hours a day, 7 days a week, 365 days a year. For most users this option is bad, because you have to have a certain level of computer knowledge to set up or manage self-hosted.
4. delta-chat as a browser add-on or
the disadvantage of this idea is that webassembly does not have the necessary resources to make this option interesting
5. only serverless/unhosted for desktop: ipfs(frontend), backend(mobile) for desktop - the proposal you suggest. and api/restful/ajax written in rust(in mobile).
As I understand it there would just be a mobile compiled UI and the web interface would be rendered by the browser into an ipfs address. The user would only have to have a dns address pointed to ipfs or even the ipfs address to access directly in the browser.
The advantage of this software architecture is that you don’t need to install anything on your computer. You would have to install only the mobile version to send or receive locally and offline synced email messages with web or desktop.
Another advantage of this idea is that you could have just one compiled version and another version just rendered, rendered by the browser from an ipfs address or custom dns address to ipfs.
In theory this architecture would be faster, because the entire frontend part runs separately from the backend part. The backend part, in turn, depends exclusively on the user’s cell phone hardware to function. Another advantage is that even if the user’s hardware is old, this will still work with certain performance and speed.
A final advantage is that each user can create custom instances of the delta-chat frontend on different types of networks, such as: i2p, tor(onion), hypercore, dat, ips, freenet, etc., to guarantee certain anonymity, security, control or privacy.
The downside is that whenever the graphical interface changes, a new ipfs address must be generated and must be associated or not with the custom dns, if that option is interesting and preferable. But this would happen only through the web version and not through the mobile version. Because the web version is different from the mobile version.
The final downside is that the web and mobile versions are different. As they are different versions, the code of the versions is also different.
Another disadvantage is that someone would have to be responsible for hosting the web version on some network protocol, server.
Notes
In cases one would like to try such for non-commercial and harmless and liberating purposes, “family-like privat”, dedicated foremost toward peaceful-ones and those wishing following them, sangham.net (sure my person has not much technical knowledge) should be open for such. Just thought to let it be known.