Proposal to start a new implementation of Thunderbird based on web technologies

Post by hilbert42 » Fri, Apr 21, 2017, 3:03 PM UTC

bhauer wrote: post #180

cakeface wrote: post #11

Does anyone actually have any problems with Thunderbird? I feel like it is "done" software. It works, perfectly, for all my needs. It's fast. It has great UI. It lets me read and write email.

For what it's worth, I like the proposal, in large part because it is a rewrite with an aim to implement a full-featured cross-platform mail client. Something fresh but with the spirit of Thunderbird and consistent with the Mozilla credo appeals to me. But to answer your question, I and several others I know whom use Thunderbird consider it a "least awful" choice. It's less complicated, opinionated, and buggy that Ou…

Post by Certhas » Fri, Apr 21, 2017, 3:59 PM UTC

dotancohen wrote: post #142

Certhas wrote: post #119

Earlier quoted context omitted.

As a result of this thread I have tried the Nylas mail client which has a javascript UI, and I am very pleasantly surprised by just how smooth the UI is. Honestly, if I could use it without a Nylas account I would very seriously consider it as a Thunderbird replacement. From reading the original email thread it also looks like the Thunderbird guys are paying attention to Nylas.

VSCode and Slack are two other Electron apps with snappy UIs. Though I commend the devs on their snappy UIs, both those apps churn the CPUs and consume crazy amounts of memory. They absolutely kill the battery on laptops and make other applications unusable. I do not want my mail client or any other app that should be always running in the background to be written in Electron.

Post by carussell » Fri, Apr 21, 2017, 5:12 PM UTC

dboreham wrote: post #177

WalterBright wrote: post #173

Earlier quoted context omitted.

It needs end-to-end encryption. This isn't hard to do. Add a field in the header for your public key. When receiving mail, store the sender's public key in the address book. Then, when sending mail, if there's a public key for the recipient, then encrypt it. No user interaction is required.

Hmm. I can just about remember Jim Barksdale personally telling every employee that the new E2E encryption feature (PEM probably?) in Messenger had to be dog food tested. In 1997.

Post by WalterBright » Fri, Apr 21, 2017, 7:35 PM UTC

pjc50 wrote: post #216

WalterBright wrote: post #173

Earlier quoted context omitted.

It needs end-to-end encryption. This isn't hard to do. Add a field in the header for your public key. When receiving mail, store the sender's public key in the address book. Then, when sending mail, if there's a public key for the recipient, then encrypt it. No user interaction is required.

> This isn't hard to do Yes it is. Or someone would have done it by now. > When receiving mail, store the sender's public key You mean "the public key associated with the inbound email". You don't know anything at this point about how it relates to the person you're intending to correspond with, because the key could be MITMd. Also, this approach does nothing to solve the fact that most people would prefer webmail an…

Post by sctb » Fri, Apr 21, 2017, 9:51 PM UTC

_eht wrote: post #133

forgotpwtomain wrote: post #125

Earlier quoted context omitted.

> If they could pull off what Atom.io/Github did for the old ingrained IDE world in a mail client, that would be incredible, IMO. You mean give hipster programmers an editor where one can literally see the delay between typing and something appearing on the screen?

Is that your experience? Dang. That must suck. I don't need you to tell me your age, I can deduce it by your general attitude towards 'hipsters.' Who hurt you? Who replaced you?