Live data from Hacker News

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

ivelope.com

381–390 of 608 posts

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

#381
post #356
post #341

Earlier quoted context omitted.

Does that support HTML email and images? If not, it seems like a different domain entirely. Other people in this thread have posted Thunderbird numbers and they're in the ballpark. After all, it is rendered in Gecko similarly to how ivelope is rendered in Electron.

Remote images in email is an anti-feature[0]. And if the images are attached to the email, why not just use an image viewer? Does your email client support video playback? [0]: https://senglehardt.com/papers/pets18_email_tracking.pdf

That's fine, but there's no point comparing RAM usage between completely different apps like video players and email clients.

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

#382
post #372

Earlier quoted context omitted.

You can audit the code of every Electron app, so why are you acting like it's full of spyware that you'll never be able to have privacy with?

Ever heard of minimized JavaScript[0]? [0]: https://github.com/google/closure-compiler

Minified js isn't particularly hard to reverse engineer compared to tools that are geared towards actual obfuscation, and regardless, you don't even need to look at the code if all you care about is privacy. A look at the dev console's network tab should tell you all you need to know.

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

#383
post #262

I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.

My partner actually has the opposite pain-point: She wants an e-mail client that stores attachments remotely, only downloading them as requested by by the client. Is there an e-mail service that does things this way?

Can't Thunderbird do that? I'd imagine most IMAP clients do this.

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

#384
post #376

Earlier quoted context omitted.

I dislike tricks like this too, especially because in the end you're still going to get access to it. If a product is good enough, as you said, then I'll tell everyone about it. I think technical or non-business people see this kind of trick and perhaps don't think of the deeper consequences of it - it's not quite a dark pattern, though it feels manipulative.

I'm sorry if it came across as manipulative. One of the reasons for having it like this is also so it can give me a metric on who in the waiting list are most interested in the program. And of course also to offer an incentive to share it.

That is not a good metric. There's no way I would take part in that even if I were interested. It's just a big turn off.

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

#385
post #262

I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.

Seems to be a proprietary application so app privacy went out the window already.

It's still better than it would be if it was a normal web app hosted on his server.

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

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

#386

I put my name on the waitlist, but instantly lost interest and confidence by: “Jump forward 5 steps in the line for every person you invite and get beta access sooner.” Why? If the product is that good I’ll evangelize it. This is a desktop application, so I don’t see a big boost from a network effect. All this does makes me wonder if the product is more about building hype than value

I think that that one email app that got acquired by dropbox before even launching did this and I think people are just copying it.

Yeah, Mailbox app used this prior to it's Dropbox acquisition. Mailbox is now a dead product. RIP.

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

#387
post #262

I don't think this puts enough emphasis on the fact that it is a local client and not a web service. I see some people here griping about Electron, but the privacy implications of being a local app are way more important than the performance of the framework used.

My partner actually has the opposite pain-point: She wants an e-mail client that stores attachments remotely, only downloading them as requested by by the client. Is there an e-mail service that does things this way?

This is what Ivelope is currently doing :) However there will be a setting for people who want to download all attachments as well.

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

#388
post #382
post #372

Earlier quoted context omitted.

Ever heard of minimized JavaScript[0]? [0]: https://github.com/google/closure-compiler

Minified js isn't particularly hard to reverse engineer compared to tools that are geared towards actual obfuscation, and regardless, you don't even need to look at the code if all you care about is privacy. A look at the dev console's network tab should tell you all you need to know.

I've done obfuscated Javascript on a CTF. Only a few hundred lines and I can tell you, it's way easier to just write it new from scratch, especially if you have a product that you like and can just copy.

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

#389

Earlier quoted context omitted.

The word web comes in when “browser” is short for “web browser”. I can’t believe I had to explain that. As for the second issue: users care because performance is worse, accessibility is by and large non-existent and platform features don’t work. For example: macOS has tabbed windows at the core - any document based app gets it automatically. How does that work out for electron apps?

> I can’t believe I had to explain that. You didn't really have to. I guess I made my point badly. The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless. And again, seems like a technicality. > As for the second issue: users care because performanc…

> The fact that a "web browser" is somewhere in the chain of what is reading an application does not mean that the application itself has anything to do with "the web", so I think calling it a web app is confusing and pointless.

In a discussion of 'native apps vs web apps' it absolutely makes a difference that Electron apps are rendered by a browser's web view - they're basically a web page rendered by a local source not remote, but without any of the sandboxing that proper browsers employ for security.

> Maybe we need a third, generic term for electron apps and others like them. A name that refers to the potential differences in performance, accessibility, and performance that users may notice?

Sure. Shit Apps (tm).

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

#390
post #376

Earlier quoted context omitted.

I dislike tricks like this too, especially because in the end you're still going to get access to it. If a product is good enough, as you said, then I'll tell everyone about it. I think technical or non-business people see this kind of trick and perhaps don't think of the deeper consequences of it - it's not quite a dark pattern, though it feels manipulative.

I'm sorry if it came across as manipulative. One of the reasons for having it like this is also so it can give me a metric on who in the waiting list are most interested in the program. And of course also to offer an incentive to share it.

I'd advise you to reword it as "Want to join as a beta user? Share".

Frame it as a reward not a punishment.

Post reply on HN