Evaluate feasibility of getting rid of server component

[Noah-Huppert]

Evaluate feasibility of getting rid of server component

[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.

[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> .

[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

[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.

[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.

[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.

[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.

[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.