Live data from Hacker News

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

ivelope.com

141–150 of 608 posts

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

#141

Earlier quoted context omitted.

1. It's an Electron app, but it is built to use as little RAM as possible, when I run it on my old Macbook Air, it consumes only around 300mb of RAM maximum, which is less than what Finder consumes, and I consider everything over this limit to be a bug. 2. Currently not supporting Mbox/Maildir but downloading emails directly from the server, however an import of this is on the todo list 3. Re: turn off conversation v…

I think SyneRyder means what format are you storing emails on disk? If a user uses your email client to download all their pop3 email, is it available in a nice format on disk for whatever reason (backups/file recovery/migration to another client)? Or is it locked up in a custom file format.

>* I think SyneRyder means what format are you storing emails on disk?*

Yup, that's what I wanted to know. Since Thunderbird & Postbox both used the same Mbox Unix format for my 20 year email archive saved on disk, it was very easy to switch between them. And since it's an industry standard, I'm reasonably confident I could export/migrate it to a new email client when I have to - or find someone who has written software to do it.

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

#142
post #133
post #74

Earlier quoted context omitted.

300MB of ram sounds like a lot to me. What are you storing in memory that is that large? If I dont use the app for 1 hour will it stop using the memory?

I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway? I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum. A quick look at the Gmail tab I have open in Chrome seems…

For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.

I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).

Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.

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

#143

No offense but unless it’s a 1st party client email clients are something that is very hard to trust. Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it. If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk. Lastly since email today is pure HTML…

There's not a lot of attack surface when JavaScript is disabled. If there's a HTML/CSS vulnerability in Chromium, then your email client is the last thing you have to worry about.

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

#144
Will definitely try it out, it’s really hard to find a perfect client.

I wonder when will we be ready to finally drop copying the entire fricking thread with each email, since all email clients automatically build the thread. If you need to forward it to someone, it’d be easier to replicate that functionality on the client side.

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

#145

Will definitely try it out, it’s really hard to find a perfect client. I wonder when will we be ready to finally drop copying the entire fricking thread with each email, since all email clients automatically build the thread. If you need to forward it to someone, it’d be easier to replicate that functionality on the client side.

Thank you! This is one of the problems I'm trying to solve - although not fully implemented yet in the beta

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

#146
post #56

No offense but unless it’s a 1st party client email clients are something that is very hard to trust. Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it. If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk. Lastly since email today is pure HTML…

I've downvoted you for your sheer negativity. This is a person who's worked 2 years on a project, in a neglected space where companies don't go because they can't make money. He deserves praise for taking the time, creating something that's different, and thinking through the idea. Well done!

Just because someone works on something for two years doesn't mean they "deserve" anything. That's flawed reasoning.

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

#148
post #56

No offense but unless it’s a 1st party client email clients are something that is very hard to trust. Who controls your client has access to your inbox with most services even the few that have separate IMAP/POP3 passwords like Hushmail can be compromised through it. If your client also integrates with encryption or worse takes charge of it my encryption key is also now at risk. Lastly since email today is pure HTML…

I've downvoted you for your sheer negativity. This is a person who's worked 2 years on a project, in a neglected space where companies don't go because they can't make money. He deserves praise for taking the time, creating something that's different, and thinking through the idea. Well done!

[deleted]

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

#149

This is just advertising... showing a product on HN, but requiring you to "invite" others? Too bad, I was actually willing to try the software. I'm not going to invite others if others can't use the software, or without trying it for myself first...

I'm sorry if it came across as advertising, let me clarify: you NEVER have to invite others to get access, however if you do, you have the chance to get access sooner - I think this is fair. I definitely understand your concern of not sharing it and you do not have to share it to get access.

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

#150

Of course I have to ask if you've looked at JMAP ( http://jmap.io/spec.html ). More because we're getting close to finishing the spec, and feedback from someone who's build a client recently about whether the spec suits their needs would be valuable!

Hi! I really like the initiative of JMAP, however I haven't been able to look into it properly - I can give you a better answer once I've done that, my email is in my profile

One of the things we’re really hoping with JMAP is that, by drastically lowering the barrier of entry (because doing IMAP/POP3/SMTP well is hard), people will be able to experiment much more, making things like Ivelope, because they can start making UI almost immediately rather than shaving IMAP yaks first.

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!

Post reply on HN