Nylas Mail Basic does NOT store your mail data in the cloud. It still uses a cloud service for some features (like read receipts), but all the data is local on your disk and auth credentials stored in your native OS keychain.

Nylas Pro currently syncs in the cloud to enable some of the pro features not currently offered in Nylas Mail Basic and to provide a much easier to use modern API wrapper around mail data. The cloud syncing infrastructure is open source and you can run it yourself and inspect the code.

All editions (both Basic and Pro) need a Nylas ID. This lets us manage subscriptions for those who want to upgrade. The code is open source on GitHub (nylas/N1). You can fork & run yourself without a Nylas ID. You just won't get any cloud-enabled features.

We never send mail, contact, or calendar data to 3rd parties. We do, however, use 3rd parties for basic usage and performance statistics and self-host as much reporting infrastructure (like Sentry) as possible.

(I build Nylas Mail)

I understand the desire to have a seamless flow from free to paid, but you can easily move this flow later in the app (a la progressive disclosure). You can even build this into the existing flow where users currently go to upgrade, by prompting the user to create a Nylas ID at that point (if they haven't already).

There's a reason that e-commerce sites allow buyers to add items to a cart without sign up, and to "checkout as guest" instead of forcing users to sign up for a Staples (or whatever) login -- you get more conversions.

Even if you prefer the approach of trying to get the information up front, adding a "skip" option that allows users to use the app without cloud sync, etc., then allowing a user to "go pro" later on at least allows people to try the app without a commitment. It's not possible to convert someone who isn't a user because they got scared away by the registration requirement -- better imo, to have a non-registered user, than no user at all.

The only reason I could think of for not wanting to allow this is related to the third party data sharing -- perhaps you plan to sell (obfuscated) user data to data brokers. If that's not in the cards, and you do not plan to monetize your free tier (aside from up-selling to pro), I see no downside to allowing users to use the app without cloud sync in the free tier, with upgrades available within the app.

Updating the privacy policy to be explicit about what data is used for ("basic usage and performance statistics") would do a lot to allay the idea that this data is being sold to data brokers (and not simply to make the app better).

It's a lot harder to monetize free->paid if you don't even know who your free users are. Requiring the creation of a Nylas ID for the free tier addresses this. Your ecommerce example doesn't fit the situation here; the ecommerce business wants the order $$ at the expense of the account, and their UX reflects that.

I remember a few years back after I got my first decent Android phone looking at "top 10" lists of the best apps out there.

One of those apps was Lumosity, and I installed it. The first step was setting up an account. I promptly uninstalled the app, and to this day, I have no idea whether it is any good.

It felt odd to me that for a game with no multiplayer component would require me to sign up for an account, and I'm not interested in leaderboards or cloud based backup either. I have the same feeling about email clients, especially when Thunderbird exists and is mostly decent.

Giving up an email account for a free "app" (and not a service) continues to feel odd to me. It almost feels wrong to call it "free", especially since it is unclear to me how my email is used.

A non-main/throwaway mail for that purpose would be a good one for you to have so you can test without giving away anything.

And a throwaway phone without any user data? (I don't think there are working Android-in-Android VMs that are both performant enough and offer good isolation.)

Thank you for making the sync engine work client-side! It's a huge step towards making Nylas a viable choice for privacy sensitive folks like myself.

The next step would be to make features like "read receipts" that necessitate signing into a cloud optional. Being able to use the app without having to sign into a cloud platform would be a much more valuable feature for me than any feature such a cloud platform could enable.

Aside: as mentioned elsewhere in the thread, tracking pixel based read receipts in particular, is overwhelmingly only used in spam and newsletters and I personally consider it to be a liability rather than a feature.

Privacy concerns are very valid. You do have the option, however, of disabling those features in preferences, so you never have to use them (or the cloud platform) if you don't want to.

(I work at Nylas)

Do you still ship the open source engine with no authentication system at all? That was a massive problem last time I checked. Sure, you mentioned it, but many didn’t read that before setting it up.

OK, You will Need to Point this out in BIG BOLD 16 Fonts somewhere. Because I have skim read through Nylas multiple times and wherever it said it requires Nylas Cloud i just bypass it right away, thinking I have to store all my Keys and Important Data in yet another third party Cloud.

So we need a cloud service for "read receipts"? Interesting.

Since those are accomplished via a tracking pixel in the email and you need to serve that image from a public server, then yes, you'll need a cloud service to run that. As stated before, you can choose to run that server yourself if you don't trust Nylas with that kind of data.

Or you could implement RFC 3798, an update of RFC 2298. It's not like these things haven't been standardized for almost 2 decades.

Unfortunately, standardization != widespread use. Tracking pixels are still the most reliable way to know whether a recipient (or many) opened your message.

Unless your recipients use email clients that don't load remote http images except on demand.

I can think of one email client with ~15 million users that does that.

Which client blocks remote images by default? Is it a cli or gui?

Gemail, Outlook.com/hotmail, thunderbird and outlook all block images, unless whitelisted... Now, there may be other providers/clients that don't, but the above accounts for a significant number of users (if not most western mail users).

Gmail does something more interesting. It shows the image by default if the url is not unique, or the image is an attachment. It also uses googles servers to download and cache the image when receiving it.

"When you get a message that has a picture in it, you see the picture automatically. "

https://support.google.com/mail/answer/145919?co=GENIE.Platf...

Gmail automatically downloads and caches images, and loads them from their server instead of from the original remote server, when you read the email.

That only obfuscates the reader's IP. Gmail respects Cache-Control headers, so it will not cache the image if you tell it not to.

Alpine, gui of sorts

K9, gui Android (think it blocks by default, or I turned off auto load when I installed ages ago).

Thunderbird, gui.

I think he meant Gmail

More like http://quetzalcoatal.blogspot.com/search/label/mailnews

Every mail client I've used, including webmail, has blocked external images by default for at least the last decade.

I believe Exchange/O365/Outlook block by default when the senders are outside the organization.

That's not a good excuse for not implementing a standard. It's also a little like saying "private investigators are still the most reliable way to know whether a person is at home": it's true, but not really a better thing to implement.

Whether a standard has adoption or not is a perfectly good consideration when deciding whether to implement it.

Neither MS Outlook nor GMail use a tracking pixel.

Such pixel are only used by newsletter or shaddy spam senders.

Tracking pixels are ubiquitous, and used in virtually almost every situation where you want to know if a person opened your email, which equates to virtually all ecommerce in my experience.

As you said, in newsletter/spam business. But common mail apps don't do that - there is already a defacto standard for that. It's clear that Nylas business is around tracking and collecting data. It's like Win10, the user is the product and everything gets collected.

Good that Outlook and other mail apps blocks third party pictures by default.

There are other mail clients that use tracking pixels, like Polymail and Canary.

The parent mentioned probably the two biggest mail clients in the world, and you mentioned 2 that I haven't heard of despite 20 years of sending email and toying around with new software.. I'm not sure it's an effective rebuttal.

So this won't work with emails coming from Gmail (and probably other providers) since these services cache these images on their server as soon as they receive them (and not when recipients open them) precisely to defeat this kind of tracking.

And of course, a lot of email clients only open such images on demand anyway.

I don't believe this is correct. Gmail will only request an image to proxy once you've opened the email, according to MailChimp, so this would only prevent tracking multiple opens.

http://blog.mailchimp.com/how-gmails-image-caching-affects-o...

It's actually hard to track down exactly when these images are cached. I don't really trust MailChimp to be truthful about this but I also can't find any specific from Google themselves about whether that caching happens when their SMTP receives the email or when the user actually opens the message.

Since Google's goal with this was clearly to defeat tracking, I would strongly expect the former, but I can't back this up.

I haven't been able to find the tracking pixel server on GitHub.

Nylas privacy policy ( https://nylas.com/privacy-policy/ ) is the single reason why I don't use it.

(puts Stallman's hat on) This is not free as in freedom.

The privacy policy looks like it should mostly apply to Nylas N1, not the newer Nylas Mail? The policy hasn't been updated since May of last year.

It looks like you need to run your own sync engine.

https://github.com/nylas/N1/blob/master/CONFIGURATION.md

https://github.com/nylas/sync-engine

Edit: Not sure what the latest update changes yet (much of the sync engine is local now?), but this thread looks like it has the latest info so far.

https://github.com/nylas/N1/issues/3166

At first I thought "shares information with third parties and that they can [copy your email]" (emphasis mine) meant that the third parties can see & copy your email. I can't find anything like that language in Nylas' privacy policy (https://nylas.com/privacy-policy/) and so I guess your "they" meant "Nylas". Given their precise business model is making synchronized copies of your email inbox, that doesn't sound very unreasonable to me.

This was exact issue I was having with Nylas. I dont understand why they want me to sign up with their server. I switched back to thunderbird now.

That's an integral part of how it works. Their sync servers download your email, then sync with your local client. You need that ID to log into their server and access your individual email accounts.

Hey – I'm an engineer at Nylas. This used to be true but Nylas Mail now uses a totally client-side sync engine.

If you're on the Basic edition, your emails never touch our servers. This was a huge undertaking (it's not easy to port a sync-engine written in Python and designed to run on servers to run efficiently on desktop machines) and is the major reason why we can now offer a freemium service. We're going to put out a blog post soon with more engineering details soon!

> We're going to put out a blog post soon with more engineering details soon!

Looking forward to it!

I think for this audience, this blog post raises more questions than it answers.

I'm a student, I can't justify $12pm (or $7pm) for an email client however good it is - but I'll gladly use the Basic version and continue contributing; pay a little back that way :)

That's awesome to hear. However I see Nylas still is requesting full "view and manage your mail" OAuth permissions server-side. Is that something that can go away?

https://www.dropbox.com/s/s37onyv41w91zi0/Screenshot%202017-...

Not any more, per the post, the performance boost comes from using Gmail's, Exchange's, et al. APIs directly rather than remote IMAP sync + provide REST API for the client.

Cloud now used for "much much much much less" [0] - just tracking and stuff. Sync-engine also (?) runs locally now, I'm not totally clear on how this works but there's apparently some currently closed source stuff to become open 'soon', so it should become clearer exactly what's going on.

There's also apparently some details to follow on their engineering blog [1].

[0] - https://github.com/nylas/N1/issues/3166 [1] - https://nylas.com/blog