There is already a fastmail desktop app. It's called thunderbird. And there are many more, for all possible tastes!
You paid them for services rendered. They’ve offered an additional service they didn’t previously for no extra charge. Now you’re upset, even though you’re still getting the same service you were previously at the same price?
Electron is the most cost effective, least wasteful way to produce a desktop app on all 3 OSes. They’re providing a feature to people who wanted it, while wasting less money from ungrateful customers like yourself who don’t care. It’d cost much more to build & maintain a native desktop app when electron works just fine.
Fastmail are an awesome developer, JMAP is great, their mobile apps are great and actually offer some reason to exist, and I like their ethos as far as I can tell. None of this detracts from the fact making an electron app that does nothing other than shell a website, in nearly every case, is a waste of time.
I’d rather Fastmail ship their web client in Electron than waste engineering resources on reinventing the wheel for a client that’d get it’s own share of endless complaints from people wanting it to be more like Outlook or Thunderbird or Mutt.
But I admit that you got me curious, do you really expect a substantial increase in power consumption due to Fastmail getting a % of their customers to run Electron instead of Thunderbird? I'm really bad at this kind of back-of-the-envelope math but I struggle to imagine that it's substantial.
Like wouldn't one kid in Nebraska playing an AAA game in anger for half an hour, on one computer, once a day, use more energy than all those electron installs combined?
Lol, What do you mean your hard-earned money ? You already spent your money. It is their money now. Consumer != Investor.
Your equivalent is someone going to their local grocery store and asking them to sell stop selling Avocados because they are allergic.
That’s the beauty of open standards, everyone can choose their favorite tool for the job depending on their preferences and skill levels.
JMAP being Fastmails open source json api for email.
I don't think for instance this was keeping a lot of people from switching to Fastmail from let's say Gmail, which also doesn't offer a desktop client.
If Fastmail has an adoption problem it's still from people not wanting to pay for their email, a desktop app is not going to change that.
I could very easily imagine that if a company wants to switch over their employees from another provider where the users had an app that had email / calendar /contacts all in one app that they would like to have that same setup again on Fastmail. In the end packaging their web app in a wrapper to satisfy that need of certain customers groups doesn't seem like something that should be very controversial.
Not certainly, because that’s not how paying a subscription works. You would have to contact them too discuss directly paying for a specific feature. But potentially!
And what about them making this has detracted from your experience as a Fastmail user? I've found the desktop site to be perfectly fine, and they recently addressed my primary complain with the mobile app by allowing emails to be saved offline. I haven't found anything worrying that I feel their dev time needs to urgently address that was ignored due to this. Fastmail just works.
How so?
Recently they let through a phishing attempt against their own service. It was clearly not from them (to me) and didn't have a green dot or whatever. I was surprised and a bit disappointed that I had to see it at all.
I like their service.
The one time I sent out a mass email using another server and it arrived in my spam folder, Fastmail Customer Service gave me instructions which would allow them to look at the email and help me figure out what the issue was, but I decided not to bother and didn't use that server again.
Is that one thousand plus? (Certainly not one million plus I hope.)
Either amount is pretty bad, although I suppose if you are a well-known person that people are trying to reach, that would make sense.
If not, and it's a bunch of newsletters or spam, I think you should try to make better email choices. (Be more discretionary with how you give out or publish your email address(es).)
However, there is little movement in the desktop email app space anymore, so aside from their web app, I see no other clients supporting this.
Evolution added some nifty features lately (Markdown integration). And allows to use Client-Side-Decoration annd classic menus - usability wise awesome. Thunderbird got this year a complete redesign.
The other part are we as users.
Vote with your feet. Go to mailprovider with native app (and leave sane people alone)!
https://josephg.com/blog/electron-is-flash-for-the-desktop/
* Non-native UI toolkit
* Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
* Slow.
* Often issues with autonomous, local operation.
* Security -> Browser Engine
* Linux: Evolution, Geary, K-Mail, Claws, whatever TUI application you prefer. And Thunderbird.
* macOS: Apple Mail or Thunderbird.
* Windows: Please. Stop using Windows. You harm other people. Start with using Thunderbird :)
TUI :)
Electron is used, when a company wants to save on developer. All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
The same is true for Firefox: Almost the entire Firefox UI is written as HTML page with JavaScript. In fact, Firefox, Thunderbird and their predecessor Mozilla Suite were the first desktop apps written as webapps, and are the direct precedessors of Electron. And they also show that it can be done well. You just have to do it well, which is not easy.
There was a reason for that decision: Netscape tried to implement all its UI natively on 3 platforms - Windows, Mac and Unix -, which was too difficult in practice to keep them in feature parity. The big new thing about Mozilla - apart from the Gecko engine - was to implement the UI of the desktop app as web app, and run the same code on all platforms. That idea is the technical foundation of Mozilla.
Electron is just using that same idea with Chrome and node.js.
The only reason why using Linux as desktop today is realistic, is that web apps put an end to the monopoly of native Windows apps - which was the ultimate goal the whole time.
/Ben Bucksch Long-time core developer of Thunderbird
[1] https://searchfox.org/comm-central/source/mailnews/local/src...
For email, I mostly don’t care whether it takes too much RAM, if the app is usable. I work with it, then I close it. That’s my workflow, at least. I believe I’m not alone in this. My iPhone is the mini server that gets all the notifications for the emails I need. (By being connected with the default email client.) So, if I want to reply from my laptop, I’ll open my app. Otherwise it’s closed.
Flash was awesome. It was proprietary, unstable, insecure, but in other regards it was much better than competition at the time.
Electron is open-source, stable and secure (as long as you stay up to date).
You’re making a compliment.
> * Non-native UI toolkit
That’s a drawback, not a plus. You can’t easily style the app with CSS the way you want it (VSCode, Obsidian).
> * Massive waste of resources (CPU, RAM, Battery, Disk). Consumption of 500 MB RAM for idle is the norm.
Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
> * Slow.
Define slow.
> * Often issues with autonomous, local operation.
???
> * Security -> Browser Engine
The only real drawback so far. Can be mitigated by staying up to date.
> It is always better to use a well-working application with your native UI-toolkit
It is always better to use whatever works best for you and solves your problems. Not OCDing around technology and not playing identity wars with crazy people online.
> Electron is used, when a company wants to save on developer.
Also a big plus. Features are being delivered to all platforms with less money spent. Win-win.
> All users pay with suffering from bad UI and their hardware resources. In this case it is something nobody asked for?
You need to seek therapy if you’re “suffering” from application using the toolkit.
P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
> I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron?
Shall we discuss any of the other claims? Your security solution are constant updates?
Invests in efficiency scales with users. Most things which suck are caused by laziness and cost saving. It would be far more efficient to help either Evolution, K-Mail and Thunderbird with access to special APIs and keep them stable.
VSCode isn't really styled with CSS if you're a user. It's done by some json or yaml. This kind of hack is required: https://marketplace.visualstudio.com/items?itemName=be5invis..., and it's clearly not supported.
You know what does have theming? Win32, GTK and QT. GTK even uses CSS for it.
And unlike electron apps, when you change how a button looks in your GTK theme it affects all GTK apps rather than just the single electron app.
> Nonsense. Obsidian is sitting at 115 MB right now, zero CPU.
I just downloaded obsidian for the first time and launching it spawns 8(!) processes using a total of 827.3 MB of RAM. That's at the launch screen, before it's doing anything.
Of course it's using no CPU when idle. That's basically the bare minimum bar for any application. It's well known that javascript is at least an order of magnitude slower than C. That's where it's wasting CPU, not when it's idle.
> Define slow.
Well to start off with, I can count the seconds obsidian takes to start up. Most native apps I have installed (other than browsers) start faster than I can reasonably react.
Typing has noticeable lag, see: https://github.com/microsoft/vscode/issues/27378
And this is on a workstation computer, I don't want to imagine how terrible the experience is on low-end hardware.
> P.S. Thunderbird performs worse than ANY Electron app I’ve ever used, and I’ve been using Electron since its inception.
Thunderbird isn't a native app either. Just like electron it's using a browser engine to show the UI.
If your base is base-2, yes. (It is well-understood that when you don't have your thumb on the scale—e.g. selecting, whether deliberately or carelessly, poor/pathological code to benchmark—that the expected slowdown factor of executing on a mainstream JS engine instead of AOT is in the neighborhood of 2x to 4x. Of course browsers JIT instead of AOT out of necessity—a constraint that doesn't apply to programs loaded from disk.)
<meta property="og:description" content="Fastmail now has native apps for Mac, Windows & Linux.">
Creating a fully native desktop app takes a huge amount of engineering effort. When you factor in their target platforms (Windows, macOS, and Linux) you’re looking at multiplying that effort several times over. No one in their right mind would build a fully native desktop mail app these days, unless that’s the one thing that sets them apart from the dozens of other web-based mail services out there.
The only real benefit I see in this Electron app is system notifications for new emails, assuming people keep the app running in the background or minimized most of the time. Other than that, the web version will almost always be better and more up to date, since it’s clearly the main product.
I can totally picture people buying MacBook Pros with 128GB of RAM just to run a bunch of Electron apps, hehe.
The Electron thing is a waste of resources for a bad application.
And packaging the app in electron is relatively easy and a nice convenience for some users.
It's just that people start with HTML, and then it's just easy so slap Electron around it.
Think of ReactNative / NativeScript like QT/wxWidgets but they are compatible with html too
in og:description and other ":description" meta-tags (look inside dev-tools)
so you can assume that they changed the title later
It's much faster than Thunderbird so far for me, and more convenient than a browser tab for me, and I'm especially liking the interconnections among mail, contacts, and calendar. The best feature for me is being able to click an email link anywhere on any web page, and have it lead to the Fastmail app.
I do have two questions. The app on my macOS system is using 700MB RAM; is that for Electron? The majority of RAM is showing as GPU rendering; is that for font smoothing?
It is not strictly necessary to waste so much resources with Electron. But usually it is, because optimization also requires developer time. Even rather good Electron applications like Signal require much more resources than a native application (Gtk, Qt, Cocoa).
The right choice would be by Fastmail to cooperate directly with Evolution, Thunderbird, K-Mail, Apple Mail and help them were needed.
Funny, I've actually been sitting literally right next to the Apple Mail developers when Fastmail developers (who were sitting on my other side and across from me) helped them make Apple Mail work better with Fastmail and other modern mail servers, in various ways.
Fastmail is very active in the IETF, creating new RFCs that standardize modern email protocols [1] and adapting existing protocols to user needs [2].
Unlike Gmail and Outlook/Exchange cough cough, who I cannot even reach for serious bugs.
> native application (Gtk, Qt, Cocoa)
Do you know a cross-platform app (Windows, Mac, and Linux) that has many millions of users and is implemented natively on each of these platforms (Gtk, Qt, Cocoa, Win32 etc., respectively), not with JavaScript? I can't think of any.
There are limits in the real world. Software teams don't scale well. Corporate agendas are set 5 management levels above the developers. Most of the apps you mention have very serious technical dept that would require a complete rewrite to get out of. I speak from first hand experience of 25 years working on 3+ different mail clients, most of them with millions of users. Seasoned developers usually made their decision after much deliberation. The "right choice" (your words above) is often far more complex than an observer can possibly know.
Please don't throw peanuts at the developers from the peanut gallery [3][4].
[1] https://www.rfc-editor.org/rfc/rfc8621.html [2] Many like https://www.rfc-editor.org/rfc/rfc8474.html [3] https://en.wikipedia.org/wiki/Peanut_gallery [4] https://tenor.com/de/search/muppets-peanut-gallery-gifs
If you consider Mac and Windows sufficiently cross-platform, any of the major Adobe apps.
No, that would make using the Linux desktop impossible, if you need that app.
A less efficient alternative would be using one of these toolkits on the others platforms. Lets say Gtk? Common well known Gtk apps like Gimp or Inkscape excel well on all of these. And are better on macOS and Windows than any kind of Electron.
Back when Chrome wasn’t considered a memory hog it used native toolkits of each platform! Yes. Gtk, Coca and Win32. That was a an effort. And yes. It was fast and convenient.
Put back to begin. Nobody asked for a fat Electron build. They searched and found a bad solution for a problem which doesn’t exist. You gave the very best example for the way to go.
PS: And ** Apple for turning off the APIs for Push Mail Notification on iOS. Now mail providers need to consider own apps for iOS. APPLE! Just turn on Push Mail for all other than iCloud!
We’re living in a world with hacks for problems that never should have existed.
Most of those don't handle (catch-all) aliases correctly such as letting you compose with any aliases you're allowed to send from (without creating individual identities) or responding with the correct alias for the From address.
They also have subpar search.
Or if you gotta have a spearate app+:
Safari > File > Add to Dock
+ which I do because it's so much easier to go to my mail instead of wading through browser windows and tabs. I've been using that way for a while now
You'll still be able to do that.
Nothing wrong with offering an option for people who prefer a desktop app, you don’t have to feel like you are the target audience for everything.
I sometimes think we forget that Electron would have allowed them to ship this to customers super quickly, across all desktop platforms, and get a nice-looking application in to the hands of their customers (who probably have been requesting this for years).
So why didn't it? The company launched two decades ago
Don't complain about Google taking over the Web, when everyone keeps packaging Chrome with their applications and calling it a native app.
Did that app work on all operating systems that were in use at that time? With a simple install? On DOS, Amiga, Apple, Acorn, Unix? The same app, with the same functionality?
If not: Would you rather live in a world dominated by native Windows applications, written in C with Win32?
Naturally before that there where no phones with Email to worry about.
There were games available across all those platforms, which are a specific kind of apps.
Wordperfect is good example of something available all over the place during the 1980-90's.
Thankfully C isn't the only way to use Win32, as it was already not the case with Win16.
Just a webpage with a bundled web bowser (electron).
This is like the worst of everything. A terrible noncustomizable browser and a poor email client glued together.
Fastmail also have a decent API if you're keen to glue together a better client yourself.
What does their webpage wrapped in a fairly poor, memory hungry browser get me over just going to their website in my browser?
Agree.
> and a poor email client glued together.
Totally disagree. FastMail webmail is really good, probably the best webmail/mail client.
Actually, I would use this desktop app if it was compatible with IMAP.
Don't hate on the tech stack.
When I want to take a simple note, I'll either open apple note, Google keep, anything that is native because it opens instantly whereas you got to wait like a second for obsidian to open.
1 second is small but also long when you just want to quickly write something and move on.
So let me understand something: you obviously have a free will to not use something, but you would prefer something TO NOT exist and NOT solve problems for users, because you hate the technology so much?
In order to abide by QT's license, you have to follow the appropriate set of rules, depending on how you use it. You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program. You can use it GPL but you have to release the source to your app. Finally, you can give QT money, and use it closed source. Okay, that wasn't that complex, but those are the rules if you want to use and distribute QT legally.
This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.
I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.
[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
https://www.qt.io/licensing/open-source-lgpl-obligations#lgp...
That last sentence is key. It is a recommendation to dynamically link OR provide application source code. We don't want to be forced to provide application source code, so according to QT.io, dynamically linking is the way to go.
On top of that, there are GPL-only licensed QT modules that aren't suitable for use by closed source applications. Programs using QT on locked down OSes aka iOS and Android are subject to LGPL version 3's anti Tivo-ization clause. I'll revert to my original claim: Using QT is complex for commerical products.
Specific questions about dynamic linking and derivative works re: LGPLv3 have never been tested in a court of law, in any jurisdiction, so all we have to go on are tea leaves and armchair Internet lawyer-ing. The FSF and GNU are certainly entitled to their own opinion about their own license, but they also have a vested interest in casting as wide a net as possible. There are plenty of dissenting opinions out there, by actual lawyers. The important point is that GNU/FSF wouldn't be one deciding what's what in a court of law, a judge is. That judge gets to decide if the specific technical differences between static linking vs dynamic linking are even relevant in the first place. They might decide there isn't one!
Since it hasn't been tested in a court of law, different people are going to have different opinions on what's actually right. QT.io gives a specific recommendation on how to use their library, so I'll defer to what they have to say, but everyone's free to make their own decisions.
- Not yet, but adding support for Math blocks is planned.
- Yes, images are stored locally in the ~/user/.config/Awesomeness/attachments folder
- Yes, but only for pre-defined fonts. This is by design - I wanted the app to be opinionatingly simple. But since I got many requests for that, I'm gonna add an option in the settings for that.
- My FOSS version uses a simple plaintext editor (QTextEdit) with some Markdown highlighting. Daino Notes uses a block editor (a la Notion) I wrote from scratch[1] - this allows me to add complex blocks *in the middle of the documents* - so things like Kanban, Images - any custom component that I wish basically - so also math blocks, tables, etc in the future. It's also allows me to do nifty things like cool drag & drop[2] and the editor is even more performant than QTextEdit (especially on large texts).
[1] https://rubymamistvalove.com/block-editor
[2] https://rubymamistvalove.com/blog/drag_and_drop_internal.mp4
> Licensing costs
> Atrocious DX
> Still non-native UI
No problem at all.
Even discord is basically the same thing in the browser
hoping servo makes it better
There are so many good clients out there, and I'd rather have 1. The team focus on their core offering, and 2. the existing email client is for the same reason (limited developer time, and matureness) a much better choice for security
It's probably because people want easy access, and have all features supported flawlessly. Mail has come a long way, but there are always specific features not integrated well.
Also, most of those apps are more a thin wrapper around the web-interface, adding some interface-sugar for desktop-integration and serving as a playground for devs to test the web-apps offline-abilities.
> There are so many good clients out there, and I'd rather have 1.
I've yet to see any good client for me. They all are kinda flawed and limited, many suffering from age or not fitting modern demands. Thunderbird seems to be the only trustable Linux-compatible one which is still actively developed, and even this is app is lacking on many corners. Add-ons are supposed to fill and round up the corners, but without anyone developing them, what's the worth in having them?
Fastmail at least seems to work on developing the mail-standards, and having their own client is probably helping them in figuring out how well those improvements are working and where they are lacking.
This is from August 2019
https://www.fastmail.com/blog/jmap-new-email-open-standard/
This announcement is a slap in our faces.
# Why Electron?
Because it lets us build an app that works well across all major platforms with the resources we have available. Building an email/contacts/calendar app is a huge undertaking. Doing it from scratch on each platform is just not feasible for us.
With Electron, we can maintain a single code base across all platforms so we can move faster, and keep feature parity everywhere. More than that though, we believe it lets us build a really great experience on each of these platforms, while offering a consistent UI for our customers across all their devices. Honestly, we can never out-native Apple because by definition whatever they do is "native", even if it sucks (Liquid Glass on the Mac is … not great UX). If that's your primary consideration, you will always be better with Apple's own Mail app, so it's pointless us trying to build something in that space. (And instead we work to also make Fastmail the best service to use Mail.app with — which we believe it is!)
# Why would you use this instead of the webmail?
If you prefer to keep Fastmail in your browser, great! You can do so. But we hear from many customers that they would rather not have their email mixed in with their tabs. With a separate app you can see it in the dock, Cmd-tab to it, make it your default email app system wide etc. It also lets us integrate with the system, like the Mac menu bar and native context menus.
# Why would you use this instead of an IMAP client?
If you've ever used the Fastmail web interface you probably already know the answer, but for everyone else…
1. It's a lot faster. Compared to Apple's Mail.app for example (which is a good IMAP client!):
- It resyncs way faster when you open the app, and uses a lot less data (JMAP is so much more efficient).
- Moving between messages is quicker. With Mail.app there's often a slight lag between clicking a message and it rendering. In Fastmail, it's usually instant.
- Add private memos to emails
- Mute conversations to ignore replies
- Pin important messages to the top of your inbox
- Schedule messages to send in the future (and not need your laptop to be online then for it to work)
- See related emails when you open your contacts.
- Add events straight into your calendar
- And much more (https://www.fastmail.com/features/).
# And finally…
This is just a choice. We hope this is something that some of our customers will love, but we're not backing away from our commitment to open standards and encourage everyone to find what works best for them.
I'll try to answer any other questions as I can.
So I use Thunderbird and K-9 Mail, and occasionally the Fastmail web UI to manage masked e-mail addresses etc. That is my happy path.
I want to be tied to Fastmail because of your stellar support and good service, not because I am trained to use your UI.
By the way, fastmail.com is now in full advertising mode for this new app. It's hard for potential customers to see that you support IMAP just fine. Please show potential customers that the app is just one option as you say; not a requirement. Your website currently does not communicate that message clearly.
I use Fastmail because of the excellent mail service, customer support, sieve rules to keep my inbox manageable, and because of the little details like WebDAV that I have unexpectedly found useful for things like syncing browser bookmarks. I pay for Fastmail because it has been excellent, not because I’m captive.
This app signals to me that there may be a change coming in our relationship. One in which you may start to neglect IMAP or make it harder for me to choose my own mail client. It tells me that Fastmail might be pivoting into “growth” and treating me like a “user” rather than a paying customer. It won’t surprise me, and I can’t really say I’d be mad. Most companies get to that point. There’s probably a lot more money to be made from vendor lock-in than happy, $50 per year customers. As for me and mine, I will switch to the next small-to-medium-sized mail provider the second I get a sense that this is the direction.
(You can also read more on our open source and standards work at https://www.fastmail.com/company/open-source/)
Just so you know, the next-best provider is Proton and they're in HEAVY growth mode at the moment. Their UI is strewn with upsell widgets.
* Despite a buyout by Opera, the company's employees bought it back in 2013. This indicates passion.
* They're privately held, so they don't have to chase quarterly earnings reports; they can focus on the product instead of the stock price.
* They've been operating in the email domain for 25 years, and their other products (TopicBox, POBox) are in the same realm technically. This isn't a company randomly throwing ideas at the wall to make money.
* They charge customers for their product, so they are not looking for a revenue stream, they already have one.
I'm also highly vigilant for companies that will screw me, but Fastmail is way at one end of my risk spectrum because of the above points. I would be astonished if they would risk alienating their core audience by shifting focus away from a good email service...after all, that's their core competency.
After giving it a spin for 180 seconds, the main nuisance for me is that I can't elect to "Always show images from this sender". I use that in other desktop clients to ensure the image blocking banner doesn't end up being subconsciously ignored by me, as it will then only show for new senders who I'm not familiar with and need to be more wary of.
Also, like all banners everywhere no matter how well designed, it's ugly. In fact to be honest... this is the main reason I want the option to get rid of it.
I can understand why you don't offer that in the web app if you're storing it server side for each customer's list of saved senders, but for a desktop app where it can be stored locally, I'd value it.
> Because it lets us
The answer to the Electron question never starts with the customer.
If it wasn't for electron, they would have build it only for macos and let the windows/Linux customers with nothing. As a customer, i say it's better than having nothing.
Long time Fastmail user. Very excited for this; normally I would care if it is an Electron app but because I want the same experience as iOS/web app, it probably makes the most sense to be an Electron app anyway.
I've been waiting for a FM desktop app that provides native notifications. Will this mean that iOS notifications from iPhone mirroring will be suppressed in favour of the native app?
Why bundle as a .zip instead of .dmg?
Will search work the same with offline use?
A few thoughts (no need to respond): I want all my messages available offline (and can confirm this is a setting), I want the same interface as the iOS app and the webmail app especially since they handle aliases and catch-all aliases including replies properly.
Edit: looks like when using iPhone mirroring, it doesn't detect that Fastmail is already installed on the mac, so you get duplicate notifications.
I don't use the web interface much, instead I use Apple's Mail.app. My only issue is that external email accounts (gmail) take some time to be fetched periodically. When I open the web interface and click on the tag, it instantly pulls the new mail in from the external account, but if I fetch in the Mail.app, it doesn't refresh the external accounts. So, for things that have a very short time period (confirmation codes), I still end up needing to open the web interface. I wonder if this would still be the case with the new desktop app?
I will take some time to set it up over the next days and try it out!
If I could sort by label, it'd be perfect.
I’ve got one question not about the new desktop app, but I was wondering if you’d consider adding some kind of automatic email sorting like Gmail? I feel like I’m in a constant battle marking newsletters I didn’t ask for as spam but there’s always new ones. And wish there was a feature that just automatically filtered them all in to a bucket for me.
Just to be clear, does this mean the app is mainly reusing the already existing codebase of the web-app? How much additional work went into the desktop-app?
Yes.
> How much additional work went into the desktop-app?
About 4 months work for 2 developers (but with both of them handling other things that arose during that time too).
Please add a staring functionality.
Thank you.
Unhinged.
You could also reimplement some QoL features like E2E search by building a local index of seen cleartext messages, or perform spam filtering via local NLP models—though in my experience, I never saw any encrypted spam. Threading UI might use a cleartext copy, or instead of Thunderbird's "Subject: ...", it could use a random UUID while preserving cleartext "RE: " patterns.
PGP is a very simple standard and could have become the default if not for some unfortunate client UX. If a major mail client automatically imported or generated a key on first install, required the user to write down a BIP-style mnemonic for private key recovery (PGP private key containers are quite large, so this might rely on symmetrically encrypting a provider-side backup), and attached the public key to every outgoing email—enabling end-to-end encryption automatically, with trust established on first use—I’d expect that a quarter of all human email traffic could have instantly become secure, eliminating decades of complexity built to sustain the illusion of trusted parties. A provider offerring this UX within an interoperable standard could be the only push it needs.
You might object to TOFU as suboptimal, but it has been the standard in many encrypted messaging systems: Signal, for instance, uses key servers to distribute keys and relies on users to verify shared secrets out-of-channel, as does WhatsApp. If this simple manual verification UX could be integrated with Web of Trust, it could automatically vouch for the user, showing a reference path for each of your contacts. Even without that, it is better to accept a one-time risk of key exchange compromise than to face the continuous possibility of eavesdropping.
This is just their webapp wrapped in an off-the-shelf browser engine. Hardly any development resources needed. It could have been quickly put together to tick a checkbox for some big client, the revenue from whom could help them work on features that actually matter more. None of us needs to use it. But somebody must have needed it, so here it is.
One very good reason is that Fastmail created the JMAP protocol and while work on getting it into Thunderbird started several years ago, it hasn’t progressed. So JMAP is kinda stuck (obviously Microsoft is not going to put it in Outlook).
It could’ve been a win-win-win for JMAP, Fastmail and Thunderbird to accelerate the implementation and support for JMAP within Thunderbird. This would/could help in JMAP adoption by other mail providers too.
It's likely cheaper to submit self-serving patches than to build and maintain your own email client.
> But you can't demand that they do.
Who's demanding anything?
Tauri is much less horrendous than Electron, but I’m fortunate enough to have a MacBook that’s happy to run 100 Electron apps without breaking a sweat, and it’s much easier for me to hack on a browser or web view than a native app.
Thunderbird has had a good number of QoL improvements, and the calendar plugins etc are quite niec. Just if one day search could... uhh... work, that would be nice
Fastmail does, of course, probably consider its UI chops etc to be part of their value add. Just seems like if they also want to win over people who like native clients then "here's a bunch of shit that makes native clients also work very well with our offerings" is less of a lift while being more helpful overall. Maybe.
Does it use JMAP?
Is it open source?
I’d really like to see a modern E-Mail client. Just in general. Most I’ve seen just aren’t appealing at all.
I don't think that's open source based on the blog post alone, and I don't think they have a reason to build a separate email client with advanced features. This app is likely just meant to serve the needs of the business clients that have asked for a separate app rather than using the website.
That one surprised me. I’ve been using the iOS app for, I don’t know. A decade? And I have never been able to check emails while offline.
Is there a setting I missed?
Also being able to make it your default app for email (and hopefully calendar?)
I haven’t had a chance to download this yet, but hoping that it has native keybindings. (Cmd+N) on mac for composing a new email or something similar.
I know fastmail’s built in keybindings are robust, but I can’t keep track of them all.
My main problem is that I have to put a lot of effort to not use gmail for my business because most of third-parties (like CRMs) work only/better with gmail.
Fastmail team, how about a Gmail compatible API ?
I wonder if Fastmail could log you in to Gmail in a way that's consistent with Google's security model, similar to how you can "log in with Google" on many services. I'd much prefer it over the app password thing.
However there are tons of services that require Google (or outlook) to work with your emails.
I'm sure there was some deal that didn't get completed because of this.
Also creating masked mail addresses in the first place.
- Block sender (whole domain)
- Report phishing
- Mark as spam
Because that stuff should be done on the server, not on the client and if you mark stuff as spam in Mail, it's on the client afaik.
The only thing I miss is the official API for the scheduled sending feature.
That's the only thing I would open the webpage app to do.
Have a solid, well-performing web app, that's all I care about.
I’m not a customer of Fastmail, because the laws in Australia are very anti-privacy and Fastmail is at their mercy. But my mail provider has exactly the same problem: a lame web app.
This is not a “technical person” complaint. These so-called apps look and behave worse on macOS.
Therefore I wonder if this is different (‘better’) for Fastmail. It means Fastmail also can see the contents and that is ok, I just want to move away from US providers.
And the company is based in Australia.
They're not at the top of the list for anyone concerned about privacy
to me this means this company is going to take shortcuts whenever possible instead of taking proper time to release something amazing.
and stop being nice to me, we are competing with reddit here