Posted by skeptrune 7/1/2025
Around 2008, tried to M&A regional email providers that served commercial and government enterprises throughout UK and Europe onto a more secure, standardized, and centralized infrastructure with lower employee count.
Totally obliterated by GMail and Hotmail because competing with (almost) free on something people really don't want to change once established is really, really hard even if you're gobbling up the supply-side.
Maybe it scales where there are compliance aspects like ProofPoint, but otherwise people don't want to change utility infrastructure without a big win or significant existing pain.
Times have changed but getting people to move on low cost commodity utilities with lots of options is almost like going into the restaurant industry.
I agree that "reinventing" email, or building a business based on "AI features" are both terrible ideas.
We began building Marco not to do either of these things, but simply because _there wasn't_ any actual cross-platform IMAP client.
Apple Mail exists (but is terrible) if you only have Apple devices. Lots of other options like Superhuman and Shortwave exist, but only support Gmail+Outlook.
All we're doing is building the app that should have existed 10 years ago: a cross-platform, offline-first "Thunderbird". Except far more lightweight and modern. And yes, we've built it from the ground up. And no, it's not Electron.
She still uses Thunderbird, but she stopped checking her email.
What a piece of software. I remember when I migrated from Outlook Express to Thunderbird 20+ years ago because Outlook Express had a bad habit of being vulnerable to exploits just by receiving them; you didn't need to even open the email, or download an attachment, or open the attachment. It was enough for the email program to be open upon receiving malware, and it'd automatically get it.
I've been using FastMail's mobile app and web app for 5-10 years now.
I wish there was something better, but it's good enough.
Asking for less makes me less focused on email, which is not bad.
> it became clear that they are developing a single web application, and then wrapping it with CapacitorJs to run on native platforms.
So what's the difference? When complaining, Electron is a generic term for instantiating a whole -ing browser to display a RecyclerView (in Android terms). Not necessarily a complaint about Electron in particular.
> offline-first
Humm. Does that mean you plan to interpose your own server between the app and imap? I sure hope not.
If you mean you keep a local copy of the emails, that's about how any decent email app works. Even Apple mail can do it for gmail over imap :)
I may actually be a potential customer, I'm just pessimistic. Not a fan of "join the waitlist" marketing either.
By the way, how much is a latte where you live?
Yes, we have a server runtime between the client app and the upstream IMAP provider. As does Superhuman, Missive, and any other product that actually provides push notifications. For users that see this as a non-starter, we enthusiastically recommend local-only clients – Thunderbird, Talanoa, etc.
The waitlist is not marketing. We are in alpha right now and are genuinely not ready for GA. As soon as we are, the waitlist will disappear.
No, I do not live in the bay area, or even the US.
You may consider toning down the negativity in the future.
I cannot see that not being a non-starter for anyone that actually understands it.
Everyone has their own threshold/requirements for privacy.
I completely understand your viewpoint, to be clear.
... but is there any difference wrt to runtime ram usage? It's still javascript. In my experience as a user forced to use electron apps, the runtime is a fixed ram cost but then the application expands and expands and expands...
> You may consider toning down the negativity in the future.
Sorry, but I just want to read my damn email. I'd pay for that [1] since as you yourself said, Apple Mail sucks.
I do not need any extra services and especially not a dependency on another server between my email client and my email server.
Guess it's still Apple Mail or Thunderbird (Talanoa does not seem to mention working with standard email protocols). Or ssh in and use mutt :)
[1] Clearly not as much as a SV latte per month.
> Sorry, but I just want to read my damn email
The good news is that there are literally dozens of email client options. If cross-platform sync and push notifications don't matter to you, Apple Mail and Thunderbird are good options.
Talanoa indeed operates via Google and Microsoft APIs, not IMAP/SMTP.
Cross-platform sync and push notifications are literally part of IMAP.
You are conflating things. IMAP supports IDLE, NOTIFY, and _sometimes_ P-IMAP, but IMAP is never going to trigger a push notification on your iPhone/Android.
JS needs some "evangelists" to explain this to people like me :)
> cross-platform sync
Um, if you use 5 clients to connect to the same imap server, you have "cross-platform sync" already don't you? It does seem to work for me.
> Apple Mail and Thunderbird are good options.
At this rate I'll probably become a donator/contributor to Thunderbird in at most two years :)
If we had a team of ten, we'd certainly be writing fully-native apps.
Linear, Slack, Discord. The discussion goes on ad nauseam. This thread is about email, not electron.
Perhaps you don't like the conclusions it draws?
You then put words in others mouths. Then cannot leave the thread alone. You've already been called out by failing to pander some cheap anti-Electron sloganeering to the HN crowd, too.
I suggest, if you're going to talk-up your APP, to do so by focusing on positives. Perhaps read some posts by people that promote successfully, such as patio11.
I am not putting words in anyone's mouth. Direct quotes from the article:
> The companies that actually succeed in email don't try to reinvent the wheel
> Adding "AI" doesn't solve email's fundamental non-problems
Also, the article itself details the "Electron Performance Crisis".
Draw your own conclusions – this is a discussion. We're discussing.
Most of the large marketing ecommerce/enterprise market was captured via ExactTarget/Salesforce, Oracle/Responsys/Eloqua, IBM/SilverPop/Acoustic, Adobe/Neolane/Marketo by the mid 2010's.
SendGrid/Twilio was another a few years later, Amazon SES is ok, then you have some of the smaller market players (MailChimp, Constant Contact, etc).
Hard to scale/grow a startup in any real way when there are so many fairly well entrenched solutions across industries and company sizes.
Something I’d die for someone to tackle.
OMG. How can someone say this in the age of AI spam. Legitimate emails categorized a spam. Impossibility to run independent email servers because getting blocked by the big players. Forced subscriptions to mailing lists. Tracking through images....
If I get Quantum Leaped back into my younger self, I'll start working on fixing email around 1993.
The article is AI spam
The article kinda acknowledges that it’s a shitheap that’s awful to implement, but somehow still champions the idea that it all works fine.
And what’s with the repeated jabs at the “terrible” exit rate that actually seems pretty good?
May I know what is so "terrible" about those protocols ans what "technical debt" are you talking about?
> Vendor quirks are everywhere, and it’s incredibly unreliable
That has nothing to do with actual email protocols. Generic email protocols are extremely reliable and resilient to any sorts of disruptions. I wish any of modern protocols exhibit similar simplicity and reliability.
But of course if vendor would like to add their quirks and you would like to buy that - that's your choice innit.
POP is pretty archaic and lack support for multiple clients accessing the same account.
IMAP is complex, slow and lack modern email futures threading, contacts. Clients often implement it in inconsistent matter, given there are plenty of extensions.
SMTP is not a single protocol but collection of bolted on protocols (DMARC, DKIM, SPF). Lack delivery tracking, and it is very opaque when it comes to spam filtering.
All these protocols are build on top of raw TCP. It is harder to implement any things we take for granted in http like: encryption, compression, multiplexing and debugability are not there by default.
> That has nothing to do with actual email protocols. Generic email protocols are extremely reliable and resilient to any sorts of disruptions. I wish any of modern protocols exhibit similar simplicity and reliability.
People spend decades building infrastructure, but even then only hardcore graybeard will self-host email.
There are no issues with POP and multiple clients whatsoever.
> IMAP is complex, slow and lack modern email futures threading, contacts.
What's "complex" about IMAP? Extremely simple and reliable protocol. Contacts are not part of IMAP and handled by different protocols.
> SMTP is not a single protocol but collection of bolted on protocols (DMARC, DKIM, SPF).
I suggest you to educate yourself on DKIM, DMARC, SPF and SMTP before making those statements.
> Lack delivery tracking, and it is very opaque when it comes to spam filtering.
It DOES have delivery tracking. Spam filtering is not a protocol feature and it shouldn't be. I suggest you again to educate yourself.
> All these protocols are build on top of raw TCP. It is harder to implement any things we take for granted in http like: encryption, compression, multiplexing and debugability are not there by default.
Let me tell you one of most hidden secrets in the industry - EVERYTHING we have online is built on top of raw TCP. Ok, and UDP as well. Every bloody fancy JS framework or mobile app you can think about is written on top of that raw TCP. Crazy world huh?
> People spend decades building infrastructure, but even then only hardcore graybeard will self-host email
If you don't know how to build something doesn't mean it's left out to "hardcore graybeards". You got to admit you just don't know how and either learn or surrender to companies who know, offering the same for a buck. It's pretty simple.
POP3 in standard only have "Leave a copy on the server" but lack synchronisation mechanism.
> I suggest you to educate yourself on DKIM, DMARC, SPF and SMTP before making those statements.
You cannot use SMTP in real world without these protocols. Your messages would automatically land in spam folders of big providers. For example, if you want to send email to Gmail, you need SPF and DKIM [1]. Any half decent implementation of SMTP need to support all these protocols [2].
[1] https://support.google.com/a/answer/81126?hl=en
[2] https://github.com/stalwartlabs/stalwart
> It DOES have delivery tracking. Spam filtering is not a protocol feature and it shouldn't be. I suggest you again to educate yourself.
SMTP have extension for DSNs (Delivery Status Notifications) but crucially it does not provide information if/why email was classified as spam. This is a reason why many website registration form have “check spam folder”. SMTP deliverability is a hard problem both on protocol level and infrastructure on spam filtering[3].
[3] https://blog.paranoidpenguin.net/2020/02/self-hosting-email-...
> If you don't know how to build something doesn't mean it's left out to "hardcore graybeards". You got to admit you just don't know how and either learn or surrender to companies who know, offering the same for a buck. It's pretty simple.
I spend a significant amount of time investigating feasibility of building an email product and build some libraries for email protocols. It is not just my opinion but other HNs users including OP. Search HN for "self hosting email" for others people experience.
Would you explain what do you mean under the "synchronisation mechanism"?
> You cannot use SMTP in real world without these protocols.
You absolutely can. GMail is not the only email provider out there.
> SMTP have extension for DSNs (Delivery Status Notifications) but crucially it does not provide information if/why email was classified as spam. This is a reason why many website registration form have “check spam folder”. SMTP deliverability is a hard problem both on protocol level and infrastructure on spam filtering[3].
I find it hard to even start commenting this, only can suggest you again to educate yourself. Spam related matters were never a part of transport protocol. And never will be for obvious reasons. Just because you would like them to be, it won't change anything.
> I spend a significant amount of time investigating feasibility of building an email product and build some libraries for email protocols. It is not just my opinion but other HNs users including OP. Search HN for "self hosting email" for others people experience.
Happy for you to actually explore building software, but we can't carry discussions just because some HN users carry some, possibly erroneous opinions, or can we?
The underly technology is very reliable. Email not getting delivered to the recipient is more about low/no-cost providers preferring to filter almost all messages rather than spend money on doing a good job of spam filtering.
I will never understand where this sentiment comes from. I've run my own mail server for like 7 years at that point. It's so incredibly rare for my mail to not deliver that I can't remember the last time I had to debug it. The most annoying thing I've had to deal with was dovecot breaking compatibility with their config format, but even that was a couple of hours of work to get back on track.
My most surprising experience was when I broke the mail setup while migrating servers once. Postfix was down for something like 7 days before I got around to fixing it. The cool thing was what happened after I fixed it. While my server was down, the other relays had been dutifully holding onto my mail, waiting for me to once again accept it. So after a week of downtime, I still got all my mail within 24 hours after starting up my server again.
That's fucking reliable in my book.
lol thanks but no thanks
10% of attempts to monetize new ideas might just be a basal level, since the root issues (humans, often without formal business training nor experience) don't change with technological implementation.