I've spent the last two years building a new email client

It's actually dangerous and unethical TO put my name behind this untested product. It's not open source, and I'm being asked to put my seal of trust and approval on their project. That's a hard no.

Incredibly hyperbolic

Where are the boring products without dumb marketing techniques to generate hype, with actual things to show other than a waiting list?

Plus Gmail and a few others big names in webmail require a HTTP client for authentication if you want to use their proprietary sync (granted there's also POP3 and IMAP. But while IMAP is good in a number of ways it's still far from perfect).

Is it inconsiderate for Ford to make a larger SUV because your garage doesn't have unlimited square footage and you only want to buy so much gas? Of course not. Why is this any different? You can decide not to buy the SUV just like you can decide not to download this application.

I think the problem is Chrome, which the Electron runtime requires. Each separate Electron app has its own copy of Chromium in memory. (What happened to shared libs?)

I see two ways you can help:

(1) you can try to get memory-usage-reducing fixes into Chromium, or,

(2) you can build an Electron-compatible runtime that uses less memory (maybe by transpiling it into code that runs on a native toolkit, and not having a static copy of that runtime per-app).

So it's not electron vs native, it's electron vs nothing.

You're free to use gnus, notmuch, mu4e, whatever million other variants if you're so concerned about your "precious" resources. This electron app that's been built has some neat features that a lot of people might find useful, like that search seems pretty cool.

> You can make pretty x-platform apps in JavaFX, QT Quick, GTK, hell even Lazarus, and they don't eat CPU and memory like Electron does.

lol, if those are your idea of pretty... The reason Electron is popular is because those frameworks are, and have always been, garbage for garbage software.

Slashdot got like this eventually. Slashdot was tech site full of luddites complaining about anything new. Worse, slashdot stopped becoming relevant. When the top comment on an article about increased hard drive space was "why does all this stuff take so much space? bloat!! lazy developers!!!".... it's pretty lame.

300mb of ram is nothing. Your OS will swap the software out when you aren't using it and it will be no big deal. People need to stop micromanaging their computer and go do more productive things with their time....

Or, at least, it has the potential to be better.

I strongly prefer to disable conversation view, because the time (recency) and time interval (frequency) are obscured, at least from the inbox view of most readers.

There is a big difference to me between a thread with 10 emails in one morning, versus one with 9 emails over a week, followed by one this morning.

150-300MB seems more than acceptable for a local email client. A pedantic, vocal minority may be over-represented in this thread (it IS HN after all).

IMO Electron apps present significant advantages that justify its negligible cost, eg skinnable with CSS, inspected live with a web inspector, cross platform etc.

I feel bad but you have already lost me there :/

Great work by the way!

For a email client that is still more than I ever would accept. Do you hold all conversations in the RAM for searchability or something?

1. Is there an extension architecture, that I might be able to write my own extensions?

2. Can I edit the "From" address on outgoing mail, and will it remember my preferred "From" address on a per-recipient basis?

3. Does it have extensive keyboard shortcut support, or does it require a mouse?

4. Does it work well with both of the Linux clipboards, the standard system one and the X-provided middle-click one? (Other Electron apps, such as Postman, do not)

Designed emails using HTML are used by marketing teams - not by people. I don't care to read emails from marketing teams "as intended to be viewed". Show me the email and let me read an email that's just a bunch of plaintext markup.

Or for advanced situations "selectively efficient" - using something other than Electron for an app that is intended to be cross-platform because [insert-alternative-here] is smaller/faster/other may be an example of premature optimisation and using something else (especially where that involves learning something else) could mean trading off elsewhere.

Not just Electron but Sciter too in that sense.

"electron can have a small fingerprint if the dev team is carefull/good enough"

Only to some extent. You will have two separate process (at least) in any case and so two sets of the same system libraries loaded in them, IPC between them, etc.

Main task of browser engine is to provide safe browsing experience. Presenting HTML is only second its task and so browser based UI will always be sub-optimal (at best).

In terms of Electron, I have installed: Slack and VS Code (although I later uninstalled VS Code, and will have to put Slack on a machine with more memory than the VM it's in now).

I can usually spare the memory, at least on my non-crap machines, but I haven't really had the need to.

I have a talk planned entitled “building a fair dinkum email client in half an hour with JMAP”—because you genuinely can make a basic but useful email client that quickly! (I’m planning to submit it for Strange Loop. Any know of other conferences that would like such content?)

JMAP’s support for both labels and folders may be helpful for Ivelope too.

I love seeing a new approach to an email UI, based on the same old email that still works. Thanks for making it!

I'll be in Munich in June for M3AAWG and then popping over to Paris to meet the Linagora team and chat with them about their JMAP work - don't think I can come up with an excuse to visit Sweden this trip sadly :(

My next trip after that is Montreal in July for IETF102. Hopefully we'll be finalising core and mail specs at that conference, hence the interest in getting feedback now! Easier to fix spec issues before publishing.

I've done a bunch of implementation on two different servers, so I'm comfortable with that half, but we only really have one client implementation in-house (hence wanting to chat to Linagora about theirs!)

JMAP-Proxy is sitting slightly behind, that's on me.

Less up-to-date, there's a few, atmail, Apache James (via Linagora), a couple that aren't published.

Why do you think it is good?

There is nothing that says that you can't have both web and native mail clients.

And gmail isn't your mail, it's Google's mail. A mailserver that you host yourself is your mail.

IMHO this is justified since people often overlook how critical an attack vector this would be.

Imagine if a state-sponsored "hobbyist" posted a pet project like the OP to Reddit and started harvesting keys/password reset capabilities for huge amounts of users.

Hell, people flocked to use unroll.me and then it turned out they were (predictably) scraping your entire inbox and selling the data to advertisers.

I don't believe that worrying somebody's skepticism might hurt feelings is a legitimate reason to downvote (remember, downvotes aren't about whether you agree with somebody; it's about whether they add constructively to discussion).

Aside: Great work OP. Seems like an incredibly hard sector to make traction with though, so best of luck.

No body is detracting anything from anyone but there is no way I’m trusting an application that can take contol of a large portion of my life without assurances.

If your email address gets compromised it’s game over for most people every service you’ve registered with is up for grabs which is also the reason why I don’t recommend anyone to use personal domains for email unless they are willing to pay for it till death do them part.

As time and time again after buying a domain that was used by someone else and setting up a catch all email address I got emails from Twitter, GitHub and the likes.

I'd honestly outsource the indexing and searching to something like mairix which is designed purely for this purpose.

(On my 4.5GB Maildir, 57 folders, 111k emails, mairix takes 205s to index from scratch. Incremental updates are <5s. Worst search I've yet done took 0.5s to return 13k hits for 'bank'.)

And yes choose your email provider based on your threat model but there is nothing wrong with Google or even MSFT for most people security wise privacy is a different concern but these are different threat models.

An email client won’t prevent my email provider from snooping on me (E2E maybe), and no email provider could prevent my client from snooping on me either.

I'm not going to make claims that a developer would maliciously embed code into their own product but I do care about the quality of their code and their security practices at large (specifically how secure is their code promotion and binary distribution supply chain).

It's not how many time you put it in it's into what and then what that thing can do with it.

Not all passwords are equal and for most people their primary email is the domain admin/root credentials for of their life.

And it isn't relevant if I personally audit every application or not I can build a trust model based on my risk appetite and the threat models that are relevant to me and the situation and everyone does it even if they are not aware of it.

I can put my trust in a specific vendor based on their business model, their reputation, the resources they have available and my experience with them and the legal frameworks surrounding the service/product. I can put my trust in the community at large in the case of open source products because while individually neither myself nor most other user validate every line of code and every commit it is possible and the community at large does do that.

Let me ask you this I this wasn't and email client but say a thick client for your online banking would you still ask me the same question? bare in mind that having your email compromised today is considerably more damaging than someone logging into your online banking as it's much easier to sort the latter and there are also considerable mitigating security controls around it.

It's the ultimate email management tool. And I hope you can add it fast.

What rumors?

I hope he's had better luck integrating spell check than the RamBox devs have ;)

edit: yes, I would love to test it and provide numbers rather than just snark - I just have to wait for the ~5,000 people ahead of me in the queue to have their software pressed to disk and posted to them before it's my turn o.0

I care... but the convenience of a webmail client accessible on any device is just so great. But there's no good way to really have secure end-to-end encryption in a webmail client. That's about the only thing that would make me seriously consider a desktop client.

Really, I'm not sure what the audience size is for email you can't see on your phone though.

Evolution somehow stores a cookie or can log in via webbrowser or something like that. Evolution will never get you logged out of your Gmail account (yes, I have one that I use for some things). I travel a lot and Thunderbird will always get blocked by Gmail (Please log-in via Webbrowser to confirm your identity).