Original author here. I have the following desiderata concerning MUA:

* it should be able to work offline (with a dedicated send/receive cycle),

* it should run fine on a Raspberry Pi (out of principle more than anything),

* it should favor plaintext mail,

* it should integrate well with all kinds of workflows and platforms (such as git email),

* it should be a veritable platform for experimentation (i.e., it should be malleable).

I think the case can be made that re-inventing the wheel can sometimes be beneficial. And e-mail to me seems rather 'underexposed' (maybe because most people think it has been a solved problem since at least Gmail).

For me, it's not just about e-mail, but our industry/discipline in general, and the state of e-mail is a good indicator in my opinion, because almost everybody uses it every day, and its implementation complexity is still rather manageable.

Besides, I'm interested in frugal computing and would like to reach a point where I can do my day-to-day stuff on a Raspberry Pi or similar device.

With respect, I do object.

End-to-end encrypted messaging does work, and Signal (among others) is proof of that.

With e-mail, either (a) you are backwards compatible and sending unencrypted (even by accident) remains a possibility, or (b) you break compatibility, but then it's no longer e-mail. (Signal is an extreme example of the latter: it just uses its own protocol.)

Signal is a good example here because someone did a usability study. In a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. The usability of end to end encrypted messaging is a serious issue. We should not kid ourselves into thinking it is a solved issue. For all practical purposes it is the issue.

[1] https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...

This is interesting, and it causes me to reevaluate my stance.

At least we have to agree on what we mean when we say that "end-to-end encryption works". I think there are `shades' of "working" if you will -- for instance, I know I mostly ignore when the key material changes in a Signal conversation, and this could be used to fool me. But then we have to talk about attack vectors and what we want to be protected from. I think it's mostly large-scale data collection and analysis rather than targeted attacks (like the CIA might do).

At any rate, thanks for setting me straight. I will read the paper!

I find your answer a bit intrusive, to be honest. Let's just stick to the subject matter instead of telling each other how unreasonable or uptight we are, okay?

Yes, "written in C" is an issue for me, for two reasons:

* I really do want to do rapid prototyping and testing hypotheses regarding MUA UX, and C is just not suitable for this end.

* I keep reading about security vulnerabilities in common mail software caused by (among others) buffer overflows.

I don't think that MUAs benefit from C the way system software (such as the kernel) does. And compared to MUAs that run in the browser, I think that the bloat introduced by using Go or Python is still justifiable. Fortunately, there already exists a MUA written in Go (namely aerc).

Yes, I totally see your point. Gmail and similar offers are convenient, which means that native software has some very stiff competition and not a lot of adoption.

I'm interested in frugal computing, and I want my software to run smoothly on a Raspberry Pi if at all possible. So I do have some demand for a native program or, rather, set of programs.

Besides, on a principle level, I fail to see how something as simple as e-mail should need (or be allowed to use) something as complicated and resource-hungry as a web browser.

> I'm interested in frugal computing, and I want my software to run smoothly on a Raspberry Pi if at all possible. So I do have some demand for a native program or, rather, set of programs.

I understand. My point is that it's likely you're a fraction of the overall "home PC" market who are fine purchasing a regular PC/Laptop/Tablet with 16GB+ RAM and multiple cores (because it's so cheap now) if that can support apps that simplify their overhead.

SO while a Raspberry Pi with a NAS that backsup to rsync.net might consume way less power and be more cost efficient, it might require technical overhead that majority of people are unwilling/unable to support/incur.

> Besides, on a principle level, I fail to see how something as simple as e-mail should need (or be allowed to use) something as complicated and resource-hungry as a web browser

From a developer of a product POV, it's much simpler and less of an overhead building a web app that runs in a web browser than a native app that runs on 5 different platforms and architectures.

Essentially the developer of products are outsourcing the headaches of 5 different platform and architecture compatibility to the web browser.

Again, I have to agree with you. I know I don't represent the majority, and I know that web apps have advantages (at least in this economy, so long as natural resources are cheaper than programmer hours). I don't argue with that. But I still find it a bit sad ;)

Thank you for responding, and for providing me with a link to your project. It is good to see that things like this exist in languages other than C. While some people on this thread in fact implied my constraints were unreasonable, I have to say I'm a bit fed up with all the statements on Wikipedia regarding security vulnerabilities of common mail software -- due to buffer overflows.

moi

And yet another example of feature creep in today's browsers. Now one can extend CSS with JavaScript.

Low coupling and high cohesion were the terms that I was thinking of, too.

Truly an impressive feat, and a lot of work no doubt. But why? Recently it seems to be some kind of fad to demonstrate that everything can be done inside a web browser. Again: why? Scope creep of web browsers is already beyond repair.

For educational uses, I have plenty of use cases for large scale teaching and learning, without backend servers and without installing anything complex on the client side.