s5806533

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 ;)

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!

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.)

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.

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.

Interesting. For the sake of completeness, it's worth mentioning that this tutorial is from 2019.

Thanks for the tip! I guess I only used webpack because vue-cli set up my project that way.

Whenever I return to the project, hell breaks loose: "npm install" (whoops, 51 vulnerabilities!), "npm audit --fix" (what now? 72 vulnerabilities? I thought this was supposed to go down not up), initialize a fresh project with the CLI so as to get the latest possible scaffolding and then migrate stuff over from the old project etc. etc. This really appears brittle to me.