HackerTrans
トップ新着トレンドコメント過去質問紹介求人

s5806533

no profile record

投稿

Ask HN: Is the state of mail user agents that sad?

19 ポイント·投稿者 s5806533·4 年前·24 コメント

コメント

s5806533
·4 年前·議論
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 ;)
s5806533
·4 年前·議論
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!
s5806533
·4 年前·議論
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).
s5806533
·4 年前·議論
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.
s5806533
·4 年前·議論
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.)
s5806533
·4 年前·議論
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).
s5806533
·4 年前·議論
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.
s5806533
·4 年前·議論
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.
s5806533
·4 年前·議論
moi
s5806533
·4 年前·議論
And yet another example of feature creep in today's browsers. Now one can extend CSS with JavaScript.
s5806533
·4 年前·議論
Low coupling and high cohesion were the terms that I was thinking of, too.
s5806533
·4 年前·議論
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.
s5806533
·4 年前·議論
Interesting. For the sake of completeness, it's worth mentioning that this tutorial is from 2019.
s5806533
·4 年前·議論
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.
s5806533
·4 年前·議論
Sometimes the other party will happily oblige with your request, but only after a totally vacuous phone call that serves absolutely no purpose other than (i) signalling how much effort the other party is spending on you (ii) punishing you with synchronous communication so as to limit your potential request rate.
s5806533
·4 年前·議論
Have used a stack like that on one application, a rather simple "knowledge vault", a few years back. It worked very well, and at the time I liked it very much. But these days, I'm no longer fond of client-side scripting (because it gets very complex very quickly, and npm+webpack is a monster). So my next stack would be closer to BCHS [1], only with Linux, Golang, and nginx instead of BSD, httpd, and C. I might add in a tiny bit of client-side scripting such as [2], but no more npm, webpack, etc. for me.

[1] https://learnbchs.org/index.html [2] https://htmx.org/ https://unpoly.com/ https://hotwired.dev/
s5806533
·4 年前·議論
> Settings → Language and Appearance → Advanced → untick Allow pages to choose their own fonts, instead of your selections above.

Done! Thanks for the reminder!
s5806533
·4 年前·議論
ActiveX was what sprang to my mind as well. But I only gave the website the most superficial look.
s5806533
·4 年前·議論
You have quite the nerve pointing out other people's alleged fallacies, while you yourself are doing everything in your power to interpret the statements of the Gemini community in a very onesided way. IIRC, the etiquette of this very place says:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

https://news.ycombinator.com/newsguidelines.html

Since this whole discussion has left constructive territory a long time ago and arguably violates these guidelines already, I will refrain from replying to this part of the discussion.
s5806533
·4 年前·議論
Thank you so much! I couldn't agree more.

Also, Gemini works for me, and it works for many other people. If the web is not to our liking, and we can't change the web, we can at least try something else (so far I'm just lurking in Gemini, I don't have a capsule of my own). I don't understand the problem with that.

As someone already said, Gemini is already in the "they fight you" phase (First they ignore you, then they ridicule you, then they fight you). It's like with veganism (no, I am not a vegan, though I sympathize).