Evaluate feasibility of getting rid of server component

[Noah-Huppert]

Hello, I found this fork after seeing the state of the other Nylas Mail repo.

One thing I was wondering is how hard (on a scale of: Fair amount of work - Not enough time exists in the universe) it would be to refactor Nylas Mail to deal with all mail related tasks locally on the system.

From reading some of the other repos issues it sounded like there might still be some things that a server is needed for. Maybe we could move as much as possible onto the client side and give up some features if you do not want a server.

Even somewhat "duct tape" seaming solutions might be good. Perhaps trying to leave all the client side code alone and make a server that runs next to the client on their machine.

I started looking at the source code but wasn't able to quickly tell if there was some sort of Server Interface class that made all the server requests. If so it might make sense to just replace the contents of those methods with the actual logic to retrieve messages from remote servers and such.

I would be willing to put in time to help out with this if it is feasible. This is by far the best looking email client I can find out there.

[tsikerdekis]

I looked into this briefly and it appears that all requests are passed to the server using an authentication id (based on nylas account). As far as I could tell, all the imap calls are passed through nylas's server. The client has no built-in support for these.

The server part is available: https://github.com/nylas/sync-engine

I haven't really tested it but in theory, if one builds from source and then switches all comms in the client-app to point to 127.0.0.1, then they should be able to get everything working. From there, we could provide users with a choice (whether they would like to use nylas's server and features or use the local client only. Btw, as long as the local client is on, reminder features and similar things like that should work the same.

Not sure if anyone is planning to tackle this but you are welcome to explore this and I can provide support as time permits. Personally, I don't use any of the nylas' features so an option like this I think may actually make the client more popular.

[Noah-Huppert]

I like the idea of running the server locally. That is definitely the simplest option which probably requires the least work.

I'll have to spend a couple days getting farmiliar with the code and then I can probably come up with a plan.

My only concern would be making sure the server runs on all supported os's alright. We might also be able to prune some features from the local one that aren't needed / won't work with just a local server (perhaps if the feature needs to be able to receive information from a third party service via call back url or something like that)

[mayurdw]

@Noah-Huppert hey, if you would prefer to talk wit us on how you are going then we do have a slack channel if you wanna join. Here is the link

Cheers

[dweremeichik]

Duplicate of #1, closing that thread in favor of this one as this conversation seems more productive.

[dweremeichik]

@tsikerdekis my understanding is that the sync engine is now included in "Nylas Mail". It was previously required when the client was "N1".

[tsikerdekis]

@dweremeichik you are correct. For some reason I assumed that sync-engine was the backend support. Doing a grep imap on the repository folders it seems that there is imap support in the isomorphic-core. So it looks like the client has what it needs to operate as stand alone (assuming nobody cares for the extra features).

I guess a step forward for this is to figure out if there is a quick way we can hack to bypass operations regarding nylas id. As far as I remember even sending mail goes through authenticating nylas id but didn't poke around much beyond that.

[Noah-Huppert]

Just checking in, I'm still interested in doing this but I'm very low on time. Progress will be slow.

…

On Fri, Jul 7, 2017, 1:25 AM tsikerdekis ***@***.***> wrote: @dweremeichik <https://github.com/dweremeichik> you are correct. For some reason I assumed that sync-engine was the backend support. Doing a grep imap on the repository folders it seems that there is imap support in the isomorphic-core. So it looks like the client has what it needs to operate as stand alone (assuming nobody cares for the extra features). I guess a step forward for this is to figure out if there is a quick way we can hack to bypass operations regarding nylas id. As far as I remember even sending mail goes through authenticating nylas id but didn't poke around much beyond that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADK2cFaV5UcOwnVuSv17yfsrAyKr6MYYks5sLcFHgaJpZM4OLaTW> .

[step21]

As others have stated, running sync-engine locally was always possible (lots of threads on nylas and elsewhere about it), but now imap stuff is local. I am also interested in it, but to me the codebase is quite huge to get into especially as I am not that fond of javascript and know even less about es6/coffeescript that nylas uses.
I briefly tried to find relevant places in the code that do the nylas-id stuff, but so far not very successful.

[ConorIA]

Looks like one of the original N1 devs is on his way to implementing a local-only (EDIT: I might have mis-read this part) version of nylas-mail.
Comment: nylas/nylas-mail#3564 (comment)
Fork: https://github.com/bengotow/N1

[step21]

@ConorIA the previous conclusion of this thread (that mail is handled locally now) is still valid, the dev just said he wants to re-implement some important parts in c++. Which sounds great, but there is no timeframe when it will be testable afaik.

[mikeseese]

I would try not to get ahead of ourselves too quickly. We do expect a large code dump from Nylas (and @bengotow's might be a contributing factor [or not]) that may do quite a bit of the work for us. I don't want us to do a boat load of work just for to get replaced by a more mature solution we were too impatient to wait on. Food for thought.

[step21]

Well, just speaking for myself here, but unless you have more info, no one knows whenever Nylas will contribute/dump anything, same with @bengotow. Nylas could go belly-up tomorrow for all we know and bengotow is one guy working mostly on the backend, it could take a while. Once he has his c++ backend, hopefully it should not be too difficult to integrate, but in a worst case scenario this could be years or might never happen. This is not to discredit Nylas or bengotow, but just speaking from evaluating the FOSS landscape for a while, where projects sometimes just die, either due to lack of funds, personal reasons or whatever despite the best intentions.

[mikeseese]

I guess I'm merely just voicing a warning/heads up so that I don't feel bad for someone to lose work and be "wtf why didn't you tell me this guy was working on stuff already?". I definitely am not telling anyone not to do it given the points you brought up nor am I saying I won't approve PRs to support this effort. Just be aware if the merging is outrageous and the dev isn't around, we may just cut out that dev's commits if we think it would better support the project as a whole.

[step21]

Sure. Thanks for that, that is def good to take into account. Thanks for clarifying.

[Noah-Huppert]

From today's blog post:

This means that if you download and run Nylas Mail from GitHub, you no longer need to login to a Nylas ID and your mail credentials are not sent to the cloud.

Sounds like they've done it for us :) thanks guys.