Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Roadmap/devlog and general discussion #1

Open
12 tasks
notpushkin opened this issue Jan 27, 2020 · 51 comments
Open
12 tasks

Roadmap/devlog and general discussion #1

notpushkin opened this issue Jan 27, 2020 · 51 comments

Comments

@notpushkin
Copy link
Owner

notpushkin commented Jan 27, 2020 •
edited
Loading

Bring back

Properly remove

Won't fix:

  • Link / open tracking: not possible without an external server and isn't ethically OK in my opinion
@notpushkin notpushkin pinned this issue Jan 27, 2020
@alexanderadam
Copy link

Awesome work, @notpushkin.

I guess it would be good if this repository could add a GitHub action for automatic building the app for various platforms (for example with action-electron-builder [repo]).

@notpushkin
Copy link
Owner Author

@alexanderadam I'm actually planning to gradually move away from GitHub ecosystem but a CI would definitely be nice! There's config for testing on CircleCI already, perhaps we could extend it with a packaging task?

@alexanderadam
Copy link

There's config for testing on CircleCI already, perhaps we could extend it with a packaging task?

Sure, it seems that there are various possibilities to push releases automatically.

However, I just saw that CircleCI is just used for tests whereas there's already a task to build release artifacts with Travis

But I don't think there are pushed somewhere else than Travis itself. So I guess it would make sense to reactivate(?) Travis and then maybe just push the releases to GitHub in the end with as described in the CircleCI blogpost?

Are you currently actively using Mailspring Libre? Is everything working as expected?

@notpushkin
Copy link
Owner Author

Thank you for your insights! A few tweaks to Travis config should do the trick (it currently fails because of some missing secrets, but that shouldn't be hard to fix). → #2

Are you currently actively using Mailspring Libre? Is everything working as expected?

Apart from the few things outlined above, yeah! I was worried that MailSync would complain but apparently it's not that tightly coupled after all.

@alexanderadam
Copy link

I guess other points that should be added to the roadmap:

@notpushkin
Copy link
Owner Author

@alexanderadam I've had PGP in mind too! Re: Mailsync – from my earlier studies it just passes JSONs back and forth, so it shouldn't be too hard to analyze and reimplement. (Thanks for your PRs by the way – I'll take a more thorough look this evening!)

We can also tweak the remove-tracking-pixels package into removing all tracking pixels altogether (it's not a panacea by any means but at least it's a bit of help in cases you want remote images).

@walterchris
Copy link

+1 for the PGP Support. So this Fork is for open-sourcing the remaining parts of mailspring and adding features on our own? I'd like to support implementing PGP.

@notpushkin
Copy link
Owner Author

Regarding PGP support, https://github.com/NgoHuy/mailspring-keybase might be a good starting point (although it didn't work for me IIRC). Anybody wanna pick it up?

open-sourcing the remaining parts of mailspring

Eventually, I hope so!

Feature-wise, I think what we need is a proper plugin store, so that everybody can setup their client according to their needs. It's in Mailspring's roadmap but apparently it's not coming anytime soon.

@notpushkin
Copy link
Owner Author

notpushkin commented Feb 3, 2020 •
edited
Loading

For those interested, you can grab a stable version with telemetry-removing patches applied here (Linux only for now).

P. S. Nightly builds are now available too! Only for Linux again, PRs welcome for Windows / macOS or (for the brave souls who fear not death) FreeBSD. To grab one, go to Travis, open latest master build and in the end of the log you'll see it in the “Deploying application” section (alright, I know, this could have been easier).

@notpushkin notpushkin changed the title I'm gonna keep the roadmap here for now Roadmap and general discussion Feb 3, 2020
@RaitoBezarius
Copy link

First of all, insane and awesome work.

I'll try to watch this repository and contribute whatever I can, don't hesitate to mention me if you want some help for triaging issue or reproducing stuff, testing stuff (I'm an Arch Linux user on amd64 FWIW, I can maintain some upstream AUR package if you want).

@alexanderadam I've had PGP in mind too! Re: Mailsync – from my earlier studies it just passes JSONs back and forth, so it shouldn't be too hard to analyze and reimplement. (Thanks for your PRs by the way – I'll take a more thorough look this evening!)

FWIW, the killing feature of Mailspring is MailSync, as long as MailSync can be reimplemented while thinking about battery life & performance, that'd be terrific.

@notpushkin
Copy link
Owner Author

Quick update: master has been updated with some commits from the upstream ✨

@lefred
Copy link

lefred commented Feb 21, 2020

If you want to remove all mentions to Mailspring Pro, would you just remove it in the main code or create a plugin that will override the rendering (if possible) ?
For example on the sidebar.

@notpushkin
Copy link
Owner Author

@lefred Good question! Overriding in plugin would be tricky I guess, but we can simulate Pro subscription by just setting the respective option in our identity JSON — this should remove most of the mentions. Going further, we'd probably want to remove them altogether, but this is not the priority right now.

@notpushkin
Copy link
Owner Author

Status update: I have translation working locally, but yet need to expose the API key field in the UI.

I also want to release this as a separate package, but it uses cld which can't be compiled into the js code and isn't exposed so it can't be easily used outside of the main codebase. Investigating.

@notpushkin
Copy link
Owner Author

notpushkin commented Feb 26, 2020 •
edited
Loading

Since this fork focuses on privacy, should we replace some of the mail hosts with privacy-focused ones?

image

spoiler No, I won't actually include cock.li (because of their domain names) but their privacy policy is pretty good. OvO

Alternatively, I was also thinking about integrating with Thunderbird's Autoconfiguration standard – this way, we can skip this screen altogeher and just let users type in their email and password and we can pick it up from there. Thoughts?

@RaitoBezarius
Copy link

RaitoBezarius commented Feb 26, 2020 via email

@notpushkin
Copy link
Owner Author

Sorry for that :( Not the best joke idea, yeah.

@RaitoBezarius
Copy link

No worries :)
We can go for ProtonMail, some classical stuff I believe :)

@louis-lau
Copy link

I thought it was quite funny 😁

@RaitoBezarius
Copy link

RaitoBezarius commented Feb 26, 2020 via email

@notpushkin
Copy link
Owner Author

notpushkin commented Feb 26, 2020 •
edited
Loading

Personally, I really dislike ProtonMail for its proprietary encryption standard and business practices: even if you wanted to use custom client, you'll have to pay for their IMAP bridge – which is another reason it doesn't make sense to add it :(

A few providers I've had in mind:

  • Disroot
  • Riseup (currently invite-only)
  • Tutanota open-source but doesn't support IMAP for the same “encryption” reasons as ProtonMail, sad
  • Migadu (starting at 4 €/mo, Switzerland-based)

Now that I've thought about it, it would make sense to invite users to sign up for those instead, for existing users the Thunderbird-based “enter email/password” flow should be easier:

image

@RaitoBezarius
Copy link

RaitoBezarius commented Feb 26, 2020 via email

@notpushkin
Copy link
Owner Author

Implemented in 39ec192. Feel free to check it out once it builds!

@lefred
Copy link

lefred commented Feb 27, 2020

Nice, where can I download the draft rpm build ?
Btw, do you plan to rebase or cherry-pick from upstream for bug fixes ?
Cheers

@alexanderadam
Copy link

Personally, I really dislike ProtonMail for its proprietary encryption standard

Can you elaborate on that? Because I thought they are using openpgpjs for encryption?
Also their client and most (or all?) of their view components seem to be open.
The same is true for Tutanota.

Or do you mean that they don't expose IMAP for fetching emails (which IMHO isn't related to encryption)?

@notpushkin
Copy link
Owner Author

notpushkin commented Feb 27, 2020 •
edited
Loading

@lefred The packages are built for each push to master! You can find them on the build page under Deploying application section. Here are the most recent ones: rpm, deb

@alexanderadam They do, just in an incompatible with other clients way :') To encrypt to outside clients, they had to invent some kind of an intermediary page. The same is true for Tutanota. And yeah, ProtonMail indeed is open source too – didn't know about that!

Anyhow, they both state some good reasons, like PGP not being resistant to quantum attacks, but in my opinion this doesn't outweigh the fact that you can't easily encrypt an email to somebody on another host.

@alexanderadam
Copy link

alexanderadam commented Feb 27, 2020 •
edited
Loading

they had to invent some kind of an intermediary page

This is not the regular mail encryption support though. This is just if a ProtonMail user sends a message to someone without GPG/PGP.
It will use PGP if the PGP key of the recipient is known.

You are right for Tutanota, though. They don't support PGP.

Anyhow, they both state some good reasons, like PGP not being resistant to quantum attacks, but in my opinion this doesn't outweigh the fact that you can't easily encrypt an email to somebody on another host.

Thank you for answering. I absolutely agree with that. 👍 I one wrote about my opinion about email security in another comment.

@notpushkin
Copy link
Owner Author

Looked into PGP implementation and it seems that it proper PGP/MIME signatures won't be possible without changes to mailsync 🤔 (https://github.com/NgoHuy/mailspring-keybase seems to do PGP Inline, which is OK but undesirable). PGP/MIME encryption could work though.

Explanation: mailsync (I believe) treats multipart/encrypted and multipart/signed just like standard emails with attachments (which is reasonable). Encrypted emails have no text/* part so Mailspring renders no body at all and writes everything (encrypted.asc and another part without filename, PGP/MIME version identification) as attachments to disk, so we can just read and parse it. For unencrypted messages however this isn't possible – they have a body part and the signature (application/pgp-signature, called signature.asc). The problem is that we can only get body as a sanitized string and not as raw bytes, so we can't check the signature. Bummer.

On the bright side, I believe there are some PGP-related developments in the upstream repo, so we might as well see it included after all!

@beppe9000 beppe9000 mentioned this issue Feb 28, 2020
Closed
@Panzki
Copy link

Panzki commented Mar 17, 2020

Hi,
I stumbled upon this project a few days ago, when checking once again if mailspring allows usage without creating an account. This is my main pain point with mailspring, I don't want send my data to some third party service.
What's the current state of this project regarding the removal of the third party service from the client?

@notpushkin
Copy link
Owner Author

@Panzki Right now it works without the Mailspring account and tracking calls should have been removed, although we still need to do more thorough testing of the Mailsync part. Some functionality is lost – mainly the things that depended on the Mailspring servers.

If you're on Linux, you can try out the latest master build (deb, rpm). For other platforms you'll have to build from source right now (PRs welcome!)

@Panzki
Copy link

Panzki commented Mar 20, 2020

although we still need to do more thorough testing of the Mailsync part.

What exactly has do be done?

@notpushkin
Copy link
Owner Author

@Panzki Basically my plan is to run it isolated somehow and ensure that no connections are made except than those to IMAP/SMTP servers. It isn't too high-priority for me though, as it seems that Mailsync wouldn't do that kind of things (e. g. connecting to id.getmailspring.com even if instructed notto), at least in current builds.

@notpushkin
Copy link
Owner Author

We now have working macOS builds thanks to @exprez135! Latest master branch build is available here, and will be added for the next release version.

Windows builds are available too on AppVeyor, made possible by @louis-lau. I'll bring it into the main repo once I can lay my hand on a Windows setup to try it out.

Thank you both for your awesome work! 🎉

@notpushkin notpushkin changed the title Roadmap and general discussion Roadmap/devlog and general discussion Apr 2, 2020
@Encestre
Copy link

Encestre commented Jun 1, 2020

Hi, newcommer on MailSpring here. I discovered this awesome project that pushing me forward to this great email client.
I check the backlog here, and don't see mention on auto blocking remote image on mail opening. Is this feature looks important for you to be added to the roadmap ?

@louis-lau
Copy link

@Encestre Does this setting not do what you want?
image

@Encestre
Copy link

Encestre commented Jun 1, 2020

@louis-lau : damned, that's it ! Thanks a lot.

@Encestre
Copy link

Encestre commented Jun 2, 2020

Hi, i issue this bug : Foundry376#304
Seems to be insignificant for main developer but mailspring is unusable for me due to this problem.
Does someone here have encounter this ?

@marco-brandizi
Copy link

Hi, all. Just discovered this fork. Very interesting! Any plan to make it compatible with Microsoft 2-Factor authentication? This has been the second reason why I gave up with Mailspring (the first being the enforcement of Mailspring ID).

@ayala-io
Copy link

ayala-io commented Jun 7, 2020

Hi, i issue this bug : Foundry376#304
Seems to be insignificant for main developer but mailspring is unusable for me due to this problem.
Does someone here have encounter this ?

I discovered this fork from that exact same thread that @Encestre referenced. Very excited to see progress here. I'm primarily a Windows and macOS user so once those builds are ready, I'll be happy to try to replicate my issues from Foundry376#304. Like @Encestre, the issues in that thread (and more) makes Mailspring completely unusable for me.

@louis-lau
Copy link

Windows and MacOS build have actually already been added to travis, just not yet to releases. Travis upload them to catbox.moe when done.

Latest Windows:
https://files.catbox.moe/wn3rbc.msi

Latest MacOs:
https://files.catbox.moe/6o27qn.zip

@fmiqbal fmiqbal mentioned this issue Jun 9, 2020
Closed
@lambtho12 lambtho12 mentioned this issue Jul 1, 2020
Closed
@zeigerpuppy
Copy link

Personally, I really dislike ProtonMail for its proprietary encryption standard and business practices: even if you wanted to use custom client, you'll have to pay for their IMAP bridge – which is another reason it doesn't make sense to add it :(

A few providers I've had in mind:

* [Disroot](https://disroot.org/en)

* [Riseup](https://riseup.net/) (currently invite-only)

* ~[Tutanota](https://tutanota.com/)~ open-source but doesn't support IMAP for the same “encryption” reasons as ProtonMail, sad

* [Migadu](https://www.migadu.com/en/index.html) (starting at 4 €/mo, Switzerland-based)

Now that I've thought about it, it would make sense to invite users to sign up for those instead, for existing users the Thunderbird-based “enter email/password” flow should be easier:

image

Using thunderbird-based autoconfigure would be helpful for a lot of users but still good to fall back to manual config if auto fails.

Regarding privacy-respecting email providers, GreenAnt is very good too, fully IMAP/SMTP compliant.

@technodrome technodrome mentioned this issue Dec 23, 2020
Open
@notpushkin
Copy link
Owner Author

Just an idea I've been playing around with recently: https://github.com/Mailspring-Libre/next

It's just like how ungoogled-chromium or VSCodium are built and might be a better way than painfully rebasing our changes on top of new releases (especially if we use codemods instead of plaintext patches!)

cc/ @exprez135

@MichaelTunnell
Copy link

Is this client ready to be used? I see that MailSync is not open source but not sure how that relates to the Mailspring ID system. I think Mailspring is a very interesting client but I hate the requirement for the ID system and if I don't have to use that then that sounds great!

If this is a fork of Mailspring is it still going to be dependent on Mailspring in the future? I am just curious how hard of a fork this is. If it is a true hard fork then perhaps a brand change would be a good idea as to not have collision with Mailspring. Like LeapMail
or MailJump or something like that?

@louis-lau
Copy link

I think the license on the mailsync engine only allows it to be used with something called mailspring. Without rewriting the sync engine a rename is not possible.

Seeing as @notpushkin has been playing around with patching mailspring, I'd assume this isn't meant to be a hard fork.

@alexanderadam
Copy link

alexanderadam commented Feb 5, 2021 •
edited
Loading

Is this client ready to be used?

People like me use it and the release page has some releases.
I'm not sure what 'ready to be used' means.
I'm obviously someone who uses it and there are obviously others who're using it as well but maybe it doesn't work for you anyway. In that case you might want to create an Issue.

I see that MailSync is not open source but not sure how that relates to the Mailspring ID system.

Can you pelase elaborate on that? In case something is missing, the README should be extended accordingly.

perhaps a brand change would be a good idea as to not have collision with Mailspring.

louis-lau wrote:

Without rewriting the sync engine a rename is not possible.

Exactly. notpushkin wrote a year ago:

MailSync license – it only allows distributing the binaries with “Mailspring” specifically, and while we don't change the app name itself, diverging the project name may be dangerous

@MichaelTunnell
Copy link

thank you very much @louis-lau & @alexanderadam for the quick responses and I understand on the branding issue. Makes sense.

The question I made about ready to use is just if it is considered production ready by the developers.

The part about the ID system is I don't want the ID system. The Mailspring ID system requires someone to create a Mailspring account and connect their emails to that account for stuff like "read receipts" and who knows what else. I was wondering if I can use this client without having to worry about the Mailspring ID system because that is really the only reason I dont use Mailspring as it is.

I know it says that this project is aimed to not do any telemetry but the MailSync stuff being proprietary and I dont know how it works with the ID system. This is why I asked because I just wanted to know how they relate to each other and if I can in fact use this fork without their ID system requirement.

@louis-lau
Copy link

Mailsync is just the imap part as I understand, not linked to mailspring services. Using it without ID is one of the most prominent reasons this fork exists :)

@marco-brandizi
Copy link

Any news about supporting O365 2-Factor authentication? I'd like to try this Mailspring fork but I can't use my corporate email without this feature.

@notpushkin
Copy link
Owner Author

Woooot!

Great news! Mailsync is now open source! 🎉 In addition to this, we will be making Mailspring ID optional this year. This change is actually quite significant and involved, but it's perched right at the top of our priority list.
— Foundry376#33 (comment)

@notpushkin
Copy link
Owner Author

You might have noticed we've skipped a couple builds again, and that's for a good reason – now you can use the upstream Mailspring builds without signing in to Mailspring ID! To upgrade, install latest build from the official website, then open up the Subscription pane in settings and click Sign out. All your settings should stay in place.

(You would not be getting the Pro features though, obviously :-) @bengotow I'm hoping we can work out a privacy-friendly alternative for enabling some Pro features without Mailspring ID as well?)

I would like to thank everybody who have been involved with this little project! ❤️

@sebastian-correa
Copy link

sebastian-correa commented Apr 30, 2021 •
edited
Loading

I would like to thank everybody who have been involved with this little project! heart

This sounds like a farewell, @notpushkin. Is the project continuing into the future? Or is the recommendation to use the regular Mailspring client?

The snooze, send later and reminder features are very useful!

(edit: Your second paragraph seems to show that development will move forwards as usual).

@notpushkin notpushkin unpinned this issue May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests