Hacker News new | past | comments | ask | show | jobs | submit login

You don't have to do anything. Relax. Any open source project leverages other open source projects. How is this "stack" any different?

Because it's a mail client, and it needs a server that will talk to my SMTP server and the mail client. Which means that I either need to give all my most private and important data (my emails) to this service, or I need to set it up locally. For a mail client.

> Which means that I either need to give all my most private and important data (my emails) to this service

You are already doing this unless you run your own mailserver, or if any of your inbound/outbound emails aren't GPG encrypted (or encrypted during connections with other mail servers using TLS).

Something has to receive email for you when your computer is not running, unless you simply rely on a local mailserver, updating your MX and A records whenever your IP changes, and let other mail servers queue your email until your local desktop is back online to accept them.

I am not already giving my emails to this service, I'm giving them to my email provider. I don't see what value these guys provide that's worth giving them all my mail.

That's a fair argument. In that case, they should provide an MTA you can plop down on a virtual machine that'll store your emails for you and they interface with using JMAP [1].

[1] http://jmap.io/

"JMAP is a transport-agnostic, stateless JSON-based API for synchronising a mail client with a mail server. It is intended as a replacement for IMAP. The specification is based on the API currently used by FastMail’s web app. It aims to be compatible with the IMAP data model, so that it can be easily implemented on a server that currently supports IMAP, but also allows for reduced data usage and more efficient synchronisation, bundling of requests for latency mitigation and is generally much easier to work with than IMAP."

Are you suggesting this is a complete waste of time based on your own needs? Well, fine. But I'm sure there are plenty of valid use cases for it and at the very least the architecture and libraries involved are HN-worthy.

Seems like they've addressed at least one of your concerns, and it might actually turn out to be very simple to set up locally, so here's the privacy trade-off for not using it in your case: privacy > value || privacy > work_of_local_install

Not sure I see the point you are making. Why the concern it's running a server if it is running locally? You already give your email data to another server, and even if you run your own mail server, then what's the issue with running another server yourself?

I don't want to have to keep my computer on and connected to the internet 24/7 for something my mail client does anyway. I don't see why someone would architect a mail client like this.

I can't see why you would need to run your computer all the time. Why do you think this is necessary? You just turn on your computer and the sync service restarts where it left off. Just like Thunderbird, or any other MUA.

But I can see plenty of reasons the design was chosen. If you are bringing in lots of mail accounts, having it running as a daemon isn't necessarily a bad way to go. A sync program doesn't need to be associated with a tty, is better off run in the background in its own process, is arguably more extensible in design terms, doesn't necessarily take up any more memory than a regular executable, allows for multiple UIs (e.g. terminal program, Gtk+ GUI, WxWindows GUI), seperates processing from the UI, lots and lots of reasons.

Maybe the developers can step in here with a response?

You can make a UI to turn off the service or use the command prompt, if that's the concern.

If you can give me a valid technical reason running the sync part of the program as a daemon is bad, I'm definitely all ears though.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact