6 ms·

Here's what you need to install to run the entire stack locally: https://github.com/nylas/sync-engine https://github.com/nylas/sync-engine Sorry-- launch day c

by grinich 11y ago

Here's what you need to install to run the entire stack locally: https://github.com/nylas/sync-engine https://github.com/nylas/sync-engine Sorry-- launch day craziness :) More docs to follow soon!

StavrosK 11y ago
Why do I need to run a whole stack for a mail client? It's a mail client! Why is everything JS web services :(
- webXL 11y ago
  You don't have to do anything. Relax. Any open source project leverages other open source projects. How is this "stack" any different?
  - StavrosK 11y ago
    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.
    - chris_wot 11y ago
      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?
      - StavrosK 11y ago
        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.
        chris_wot 11y ago
        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.
    - webXL 11y ago
      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
    - toomuchtodo 11y ago
      > 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.
      - StavrosK 11y ago
        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.
        toomuchtodo 11y ago
        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/ 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."
- drdaeman 11y ago
  At least half of the blame should be not on them. IMAP doesn't know a thing about what happened to email in last 10 years (few minor exceptions apply). They're merely implementing their own means to access email in convenient and modern way. Say, IMAP has no labels[1] or contacts[2] (and many other things) - there are proprietary extensions, MS Exchange being the most famous one, but they're... proprietary. And given that proprietary implementations differ, it makes sense to create an unifying wrapper. And JS apps and web services are just an approach that's trendy today. Personally, I don't like it either, but can't blame for going with the flow. Especially since it's a business (and going against the flow has costs, both in development and adoption), not a private project where one can do things in a way that just feels right, ignoring anything else. I believe it would absolutely make sense to bundle the "sync engine" within the mail client, though, to make it standalone. But I understand it's done this way just because there was only the engine (as a service, not a library) at the beginning. ____ [1] https://nylas.com/docs/#labels https://nylas.com/docs/#labels [2] https://nylas.com/docs/#contacts https://nylas.com/docs/#contacts
  - nadams 11y ago
    > but they're... proprietary Everything you ever wanted to know about Exchange [1] (but were afraid to ask). I personally use SOGo [2] as a Exchange ActiveSync provider but I know OpenChange is a project to implement the entire Exchange stack. So I would not consider it proprietary. [1] https://msdn.microsoft.com/en-us/library/cc307725%28v=exchg.80%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/library/cc307725%28v=exchg.... [2] http://www.sogo.nu/ http://www.sogo.nu/
  - tormeh 11y ago
    >IMAP doesn't know a thing about what happened to email in last 10 years Sounds like it's time for a new protocol, then. Is anything in the works?
    - e12e 11y ago
      JMAP? http://jmap.io/ http://jmap.io/
  - 11y ago
- nadams 11y ago
  I completely agree - things needs to be simpler not more complex. I believe a quote from Albert Einstein fits here: > "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Though I think I get why this email client and Android's Outlook [1] will hoover your emails to some other server - the server may have more processing power than your device. And/or use an RDBMS to index the emails which is better suited for a server than a smartphone. And that's fine - but the email client should be able to do this on it's own without the need for a server (and explicitly show a warning/message allowing you to opt-in to using the third party service). It will be slower indexing emails on your phone but that is the price you will pay. And to be fair - I've tried almost every email client I can get my hands on: Evolution, Foxmail, Pegasus, Thunderbird, Outlook, ElementaryOS. To date no one has gotten calendar, contacts, and email better integrated than Outlook. Trust me I REALLY REALLY REALLY don't want to use Outlook - but I've yet to use an open source alternative where in 5 clicks or less I am syncing all those items previously mentioned. Thunderbird comes in second place - but I have to install 2 different extensions for contact and calendar syncing. The contact syncing has been hit/miss and the calendar syncing was stable for the most part. I should note that I don't use Exchange but I use iredadmin with SOGo. I think SyncML was supposed to solve the whole syncing problem - but never really took off. [1] https://play.google.com/store/apps/details?id=com.microsoft.office.outlook&hl=en https://play.google.com/store/apps/details?id=com.microsoft....
- tlrobinson 11y ago
  Most mail clients have a "sync engine" of some kind, except traditionally they're not written in Python and don't communicate with the rest of the app using REST APIs. But why is that a problem? It's open source, someone should just package everything up into one nice downloadable desktop application.
  - dcposch 11y ago
    Working on it! Front-end is gorgeous. Using it to try out some ideas re: email encryption.
    - antifarben 11y ago
      Did you already start a plugin by yourself? If yes you should perhaps mention it on the roadmap (or vote for it otherwise): https://trello.com/b/hxsqB6vx/n1-open-source-roadmap https://trello.com/b/hxsqB6vx/n1-open-source-roadmap / https://github.com/nylas/N1/issues/19 https://github.com/nylas/N1/issues/19
anseljh 11y ago
Why isn't this the default?

by grinich 11y ago

Here's what you need to install to run the entire stack locally: https://github.com/nylas/sync-engine https://github.com/nylas/sync-engine Sorry-- launch day craziness :) More docs to follow soon!

StavrosK 11y ago

Why do I need to run a whole stack for a mail client? It's a mail client! Why is everything JS web services :(

webXL 11y ago
You don't have to do anything. Relax. Any open source project leverages other open source projects. How is this "stack" any different?
- StavrosK 11y ago
  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.
  - chris_wot 11y ago
    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?
    - StavrosK 11y ago
      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.
      - chris_wot 11y ago
        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.
  - webXL 11y ago
    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
  - toomuchtodo 11y ago
    > 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.
    - StavrosK 11y ago
      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.
      - toomuchtodo 11y ago
        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/ 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."
drdaeman 11y ago
At least half of the blame should be not on them. IMAP doesn't know a thing about what happened to email in last 10 years (few minor exceptions apply). They're merely implementing their own means to access email in convenient and modern way. Say, IMAP has no labels[1] or contacts[2] (and many other things) - there are proprietary extensions, MS Exchange being the most famous one, but they're... proprietary. And given that proprietary implementations differ, it makes sense to create an unifying wrapper. And JS apps and web services are just an approach that's trendy today. Personally, I don't like it either, but can't blame for going with the flow. Especially since it's a business (and going against the flow has costs, both in development and adoption), not a private project where one can do things in a way that just feels right, ignoring anything else. I believe it would absolutely make sense to bundle the "sync engine" within the mail client, though, to make it standalone. But I understand it's done this way just because there was only the engine (as a service, not a library) at the beginning. ____ [1] https://nylas.com/docs/#labels https://nylas.com/docs/#labels [2] https://nylas.com/docs/#contacts https://nylas.com/docs/#contacts
- nadams 11y ago
  > but they're... proprietary Everything you ever wanted to know about Exchange [1] (but were afraid to ask). I personally use SOGo [2] as a Exchange ActiveSync provider but I know OpenChange is a project to implement the entire Exchange stack. So I would not consider it proprietary. [1] https://msdn.microsoft.com/en-us/library/cc307725%28v=exchg.80%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-us/library/cc307725%28v=exchg.... [2] http://www.sogo.nu/ http://www.sogo.nu/
- tormeh 11y ago
  >IMAP doesn't know a thing about what happened to email in last 10 years Sounds like it's time for a new protocol, then. Is anything in the works?
  - e12e 11y ago
    JMAP? http://jmap.io/ http://jmap.io/
- 11y ago
nadams 11y ago
I completely agree - things needs to be simpler not more complex. I believe a quote from Albert Einstein fits here: > "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Though I think I get why this email client and Android's Outlook [1] will hoover your emails to some other server - the server may have more processing power than your device. And/or use an RDBMS to index the emails which is better suited for a server than a smartphone. And that's fine - but the email client should be able to do this on it's own without the need for a server (and explicitly show a warning/message allowing you to opt-in to using the third party service). It will be slower indexing emails on your phone but that is the price you will pay. And to be fair - I've tried almost every email client I can get my hands on: Evolution, Foxmail, Pegasus, Thunderbird, Outlook, ElementaryOS. To date no one has gotten calendar, contacts, and email better integrated than Outlook. Trust me I REALLY REALLY REALLY don't want to use Outlook - but I've yet to use an open source alternative where in 5 clicks or less I am syncing all those items previously mentioned. Thunderbird comes in second place - but I have to install 2 different extensions for contact and calendar syncing. The contact syncing has been hit/miss and the calendar syncing was stable for the most part. I should note that I don't use Exchange but I use iredadmin with SOGo. I think SyncML was supposed to solve the whole syncing problem - but never really took off. [1] https://play.google.com/store/apps/details?id=com.microsoft.office.outlook&hl=en https://play.google.com/store/apps/details?id=com.microsoft....
tlrobinson 11y ago
Most mail clients have a "sync engine" of some kind, except traditionally they're not written in Python and don't communicate with the rest of the app using REST APIs. But why is that a problem? It's open source, someone should just package everything up into one nice downloadable desktop application.
- dcposch 11y ago
  Working on it! Front-end is gorgeous. Using it to try out some ideas re: email encryption.
  - antifarben 11y ago
    Did you already start a plugin by yourself? If yes you should perhaps mention it on the roadmap (or vote for it otherwise): https://trello.com/b/hxsqB6vx/n1-open-source-roadmap https://trello.com/b/hxsqB6vx/n1-open-source-roadmap / https://github.com/nylas/N1/issues/19 https://github.com/nylas/N1/issues/19

anseljh 11y ago

Why isn't this the default?