Subscribe
Share
Share
Embed
Ricardo Signes, Chief Engineer at Fastmail, explains why Gmail's email experience has become increasingly fragmented, and what it would take to actually fix the decades-old IMAP protocol that powers most of the internet. We dive deep into JMAP (the modern replacement Gmail won't adopt), privacy-by-design vs. encryption theater, and the hidden trade-offs between convenience and security that no one talks about. If you've noticed your email client feeling broken, this interview reveals why.
🔗 SOURCES & LINKS
• Fastmail: https://fastmail.com
• Fastmail Values Statement: https://fastmail.com/about/values
• Cyrus IMAP/JMAP Server (open source): https://www.cyrusimap.org/
• JMAP Standard (RFC 8620): https://tools.ietf.org/html/rfc8620
• Web Push Standard (RFC 8030): https://tools.ietf.org/html/rfc8030
• Signal (for encrypted messaging): https://signal.org
• Fastmail Data Transparency Report: https://fastmail.com/about/transparency
⏱️ TIMESTAMPS
00:00:00 INTRO
00:01:36 WHAT DRAWS YOU TO FASTMAIL?
00:03:29 FASTMAIL VALUES & PHILOSOPHY
00:08:49 FASTMAIL TARGET USER
00:12:43 LACK OF NATIVE E2EE
00:16:16 WILL EMAIL EVER BE PRIVATE?
00:18:23 FASTMAIL E2EE OPTIONS
00:23:43 FASTMAIL CLIENT OPTIONS
00:26:18 FASTMAIL INTEGRATIONS
00:29:49 BEING GOOD INTERNET CITIZENS
00:33:13 BAD INTERNET CITIZENS
00:38:26 JMAP & OTHER EMAIL PROTOCOLS
00:48:15 REAL-WORLD BENEFITS OF JMAP
00:53:07 ISSUES WITH GMAIL ON IOS
00:56:06 LACK OF E2EE FOR EMAIL WITH ADP
00:57:29 DOES JMAP MAKE E2EE EASIER?
01:00:43 FASTMAIL + OPEN SOURCE
01:10:48 PROTECTIONS AGAINST BAD ACTORS
01:14:46 PHONE NUMBER REQUIREMENTS
01:22:55 AUSTRALIAN JURISDICTION
01:25:55 THE FASTMAIL TEAM
01:28:45 PRODUCTIVITY-FOCUSED EMAIL CLIENTS
01:34:27 FASTMAIL + IMAP
01:35:49 WHY THE NAME "FASTMAIL"?
01:38:27 IS JMAP WHY FASTMAIL IS SO FAST?
01:42:03 FASTMAIL'S IDEAL AVATAR + FUTURE PLANS
01:46:25 HOW TO FOLLOW RICARDO + FASTMAIL
01:48:03 OUTRO
🎥 VIDEO
Watch on YouTube
🧡 SUPPORT TECHLORE
Keep Techlore Talks independent & growing: ★ Support this podcast ★
Creators and Guests
What is Techlore Talks?
Techlore Talks brings you in-depth conversations with the experts at the forefront of privacy, security, and digital rights. Hosted by Henry Fisher, founder of Techlore and long-time digital rights educator, each episode features meaningful discussions with the people building, researching, and advocating for digital freedom.
From cybersecurity researchers and privacy tool developers to open-source advocates and digital rights activists—if they're shaping how we protect ourselves online, they're on this show.
Topics include: privacy tools and technologies, cybersecurity threats and defenses, open-source software, surveillance and digital rights, encryption, tech policy, and digital sovereignty.
New episodes released regularly. Subscribe and join the community at techlore.tech.
I don't want to know your phone number.
I don't want to know anybody's phone number who's using FastMail.
The phone number for account verification.
Welcome to Techlore Talks.
Today I have the privilege of inviting Ricardo from FastMail on the podcast to discuss FastMail,
their approach to email privacy, how it differs from other people who use end-to-end encryption
like Proton, their approach to security, features, why they're even called FastMail, their history,
and how they still approach email security and how they still enable those options.
It's just a very interesting conversation about email.
We ended up talking for almost two hours, and so this was quite an interesting interview
that I had a lot of fun with, and I learned a lot along the way.
Now, to the interview.
All right, well, do you want to introduce yourself and just say who you are and what you're working on?
Yeah, sure.
So my name is Ricardo Cignas, Rick.
I am a chief engineer at FastMail.
Technically, I'm the chief of developer experience, but day-to-day, I mostly work with the Cyrus team,
which is our open source IMAP and JMAP and CalDAV and contact server.
But also, as a chief engineer, I'm one of the people that all the random stuff falls to.
So I've got my fingers in a lot of pies, and I try to keep an eye on everything going on here at FastMail.
And how long have you been at FastMail?
So it's a funny question, because I've been in this job for 20 years.
FastMail bought the previous place I worked, Pobox.com, which is a very similar product.
about 10 years ago. So I've been with Fastmail for 10 years, but it's sort of seamless from
the previous 10 years working on the same stuff. Got it. Why have you stayed with Fastmail? Like,
what about it do you enjoy? What kind of draws you to it? Yeah, there's quite a few things I like
about Fastmail. I think the most important thing is our values. And the technology is really
important. I like our technology and I like the problem space we work in. But I tell people this
story about just about 10 years ago when we from the Philadelphia office had been newly acquired
and we were visiting Australia and we were having a strategic planning session. And one of the
directors said, we really shouldn't be talking about long-term plans without stating what our
values are. So let me write this down. And he stood up and he wrote four sentences on a board
and all the directors said, yep, you nailed it. And like they all knew what the company's values
were, and there was no argument, and we haven't changed them. They're on our blog, and I think
that inside the company, and I hope outside, you can really see that we live those values.
Things like, we are stewards of your data. It's not our data, it's your data. We don't want to
take it. We're good internet citizens. That's why we do open source software. And these values
drive us to do work that I think is worth doing, and that makes me feel good about, you know, what I'm
doing 20 years, right? What I'm doing with my life. Working in email is sort of an outcome of that,
right? If we believe in being good internet citizens, we want the internet to be an open
set of federated systems. And email is the original social network, the original federated system.
And it's, I don't ever want to see it go away. I'd like to see it continue to evolve, which is a
tough proposition. But that's the outcome. That's, I mean, that's the second step, not the first one.
The first one is being a good internet citizen.
So that's, I know it's sort of a pie in the sky answer, but it really is what I like about
FastMail the most.
Nice.
And so when it comes to email, I'd say the majority, I mean, by far the largest provider
is going to be Gmail for people.
And so what makes you a better, and so I'm going to give kind of the, you know, both sides
of the spectrum here.
So we're going to see maybe Gmail on one end, Proton, and kind of where you guys fit and
guys approach this. So when you compare yourself to Gmail, what makes you guys a better, you know,
handler of data? How are you a better internet citizen? How do you compare yourself to that if
someone were to ask you? The answer we used to talk about a lot, and this still gets trotted out
by some people time to time, is we don't read your mail. And I, on one hand, I've never liked this
phrasing. It sounds pretty crappy towards Gmail. They're not reading your, they're not, they're not
out there to read your mail, but they have had a long history of figuring out why are they in
the email market. And some of this is about large scale data analytics, right? And even if they're
not reading your email to do super creepy things specifically about you, why are they doing this?
Right? The old saw that if you're not the customer, you're the product is,
It's a little pat, but it's not totally wrong.
And that's sort of the one big answer.
For me, it's true, but maybe more to the point for me is that I don't think Gmail is very good email.
I live in my email.
I have basically two to-do lists.
I have my email and I have our internal bug tracking system.
So everything that I've got to do in my day is in my email or my calendar.
And my calendar is my email with FastMail.
It needs to be good.
It needs to like organize itself for me.
The search needs to be like unbeatable and using it needs to be quick.
Like not just I click a message and it's immediately loaded.
That's nice, but that's almost candy.
It's when I sit down to do my morning 30 minutes, 45 minutes of email.
It has to feel like there's no friction.
Like I'm just coasting through it.
And when I use Gmail, all I feel is friction.
And some people don't care.
Fastmail is a tiny, tiny drop in the bucket compared to Gmail, right?
The people say Gmail is a competitor.
And like, technically, it's true.
80%, I think, of email addresses are Gmail addresses these days.
It's some absurdly large number.
But we don't have to think about how do we beat Gmail.
It's how do we find users who want the same things out of email that we want to provide.
And for me, many of us have different motivations, but for me, it's that seamless, fast, efficient, in and out, make your life better and get out of the way experience.
I think that's the thing that is most compelling for me in my day-to-day use of FastMail.
The support's also very good, but I don't usually have to worry about the support because I can go log into the servers, and that's not fair.
Yeah.
Did you want me to say more about the other end of that, the proton angle?
I'll get to the other angle.
I do want to first comment that on the other angle.
So I'm still a Proton user right now.
No, no bad blood here.
You even mentioned you saw the comparison before we started recording.
And so I hope that people know my position is like there's different people for each of these different providers.
And let's just say projects that I don't know if I'm allowed to say this.
So a project that I do work for has migrated to G Suite for certain things.
And I had to use Gmail for the first time since like 2015.
It's been like a decade since I've actually opened and used Gmail.
And in my head, Gmail was a really good, clean, minimal, usable email experience.
And my God, it's just not my memory at all.
I don't know if I was disillusioned to think it was good back then or if it's just gotten worse slash the same after 10 years.
But I opened it.
I just wanted a unified inbox.
Now it's like everything's broken up into different inboxes, which is a bit confusing to my brain.
Yeah.
And the settings page is just raw HTML, it seems like.
Yeah, that's a mess.
So, yeah, and it was hard to find where to even add a signature in Gmail.
So I was just very disappointed in the Gmail experience and it felt neglected.
And when I did trial FastMail, it was much cleaner.
And then I actually gained more appreciation for all of the email services, including Proton and Tuda, who I feel like I've in my head painted as worse than Gmail.
But I actually think in some ways they are.
And I do think of all of those three, FastMail is still my top for usability.
So you guys are I still think are killing that usability angle of things.
Because, yeah, it's not that you're not doing a good job, but I don't think it's hard to beat Gmail anymore.
I think both those things are, I think it's true that we're doing a great job, but also Gmail's got a tough position, right?
They're serving individual people who are signing up all the way up to 10,000 person enterprises with one product.
It's just going to be real tough.
Yeah.
So on this note, you know, I want to touch more on the other side of things, data.
But what is kind of your core target demo?
You know, if I'm on your website, it seems like you guys are pretty 50-50 individual in business.
So who's kind of your core target?
Right now, yeah, right now we're much more individual.
We have some businesses, some that are sort of sizable, but I would say mostly very small micro businesses are with us.
I would like to be more appealing to small business.
I think that we have a lot of great features.
And, you know, when I just say Gmail's got a hard time because they've got to appeal to this very, very broad demographic, it creates incentives inside.
I suspect I don't work there.
I suspect it creates incentives inside the product that are sort of competing with one another.
And they lead to this tension in the settings screen or this sort of fruit salad of options.
And we really don't want to be that.
Right. Like we we sort of have a good understanding internally that every extra button is a problem for a lot of reasons.
Every in every a button is bad enough, but like a checkbox is way worse.
A checkbox, any checkbox on your settings page doubles the number of possible configurations a user could be in.
Right. So like you don't want to mess around with just adding lots and lots of options.
And when we say we want to sort of expand to be somewhat more appealing to businesses, that means adding options.
So they have to be really carefully pitched, really carefully put together, because we want the whole product to feel just as perfect to a small business or to a team as it does to an individual.
So maybe it's a long-winded answer to part of that, but that's sort of the how are we split.
We're split mostly towards individuals right now.
I'd like to see that change in the coming year or two.
And then as a question of, well, which individuals?
Earlier I said FastMail is kind of not even a drop in the bucket compared to the size of Gmail.
So, you know, we don't have to worry about carving off 1% of their users and having a huge number of different audiences we appeal to.
The question comes down to, well, for whom are we the best pick?
And I usually start by saying, you eliminate a huge number of people by saying, start with anybody who's willing to shop around for their email.
If someone's like, I need an email account, that means Gmail.
I need an email account. That means Hotmail. There's only so many, depending on your generation.
At some point, I need an email account. It's AOL. But there's just the pick, the default pick.
Once you find someone who doesn't want the default pick, it's a pretty good definition of the starting
point for Fastmail users. And then what do you find? Well, you want people who want something
really, really fast. Not for nothing that Fastmail started in Australia, where I can tell you the
latency times are unbearable. Here, I am milliseconds from data center access. And in
Australia, like, you know, I type in and I wait for my keystrokes to show up. It's painful. So
fast mail being so fast is a function of that. You find people who want what I want,
the productivity built into their email, especially very customizable productivity,
not we have decided how you will be productive, but we are giving you a bunch of tools to figure out.
And then there's the people who are in the privacy space. And I think that your video talking about Tudor and Proton and FastMail is a good slicing of that cake.
Some people are in the privacy space and what they want is privacy. They want to know that nobody wants to use their data, that they can kind of have their own space.
And some people want secrecy. They want to know that their data is unassailable. Their data is noise as far as the service provider is concerned.
And people will look at us and kind of figure out we are providing good privacy.
We're providing decent, we're providing really good security.
And we're providing a great service.
And there's always that slider between, as you said, actually, convenience and secrecy.
And people make their choice on that front.
Yeah.
So that was, you know, definitely the big difference between you and then Tudan Proton is the lack of native end-to-end encryption.
And so why have you opted for that approach for kind of your goals?
I think that end-to-end encryption is good.
I like end-to-end encryption.
And in a perfect world, we would be able to end-to-end encrypt all of our communications.
And for us, I think, or at least for me, but I think I can speak a little more broadly,
the difficulty is that email is not well-suited to end-to-end encryption.
It can get there. I think it requires sort of systemic change, but there's a number of
significant problems. The transmission of email is built around having this RFC 822 and subsequent
standard document, and that document is in the clear. And there have been a number of attempts
to talk about how do you encrypt that document, and many of them are like, well, you encrypt this
part of it, but all these other parts are not encrypted, cannot be encrypted. And the standards
doing that are numerous and really overcomplicated, I would say, and poorly adopted. So this is the
first barrier to just having end-to-end encrypted email work. The next problem is key distribution,
right? You want to be able to email somebody from their business card and send them an encrypted
message. And on the open internet, that's kind of a non-starter. There simply is not a good
private key infrastructure or public infrastructure for doing these kind of from scratch boot ups.
This is a problem that needs to be solved for email to have the kind of convenience
for initiating and carrying on end-to-end encrypted conversations. And if you can't do that,
what you're really saying is we're going to have a sort of walled garden and the wall has to go
somewhere. It might be within our enterprise, right? You're using a Microsoft Exchange server.
You're part of Google Enterprise. Within our enterprise, all the key activation and creation
and trust is generated automatically behind the scenes and you don't worry about it. Your workplace
manages it. All the encryption happens. Everything is perfect. But as soon as you want to email outside
of your ecosystem, and that might be your business, it might be the service provider using, as soon as
you want to go outside of that, weird stuff happens, right? Either they get a message that's
like signed but not encrypted or it's encrypted but not well encrypted or it's encrypted and they
can't read it. Everything gets bad. Or you get what we see in the U.S. with healthcare providers
where you get an email and the email says you have an email. And then that takes you somewhere. You
leave email and you go to the web. And I love the web too, but I don't want my email to be pointers
to the web. That's weird. I want my email to be email. So FastMail is interested in encrypted
email. We would like to make the technology capable of doing that, but it has to stay email,
and it has to stay this open federated system. And until we can do that, I think that we don't want
to compromise on the ease of use, because fundamentally, most users do not need that
kind of security for what they use email for. I never want to say that users don't need the
ability to communicate in secret. They don't need the mathematical privacy guarantees,
but they don't necessarily need that in their email. There are other options available until
email provides that in a user-friendly way. Do you think email will provide that ever?
I don't know. It's a great question. Will it ever? I don't know. I can tell you that it's a live
topic of conversation among people who are doing serious standards work. We're pretty heavily
invested in the Internet Engineering Task Force. We tend to show up at all the IETF general meetings
and talk with other email providers and other technologies, but of course email and calendars
and contacts are our big mainstays. There's some new work right now about improving signatures on
email. Signatures are not encryption, but they give you something. The idea is giving you signatures
on your email without making the email look weird, which is great, but it's almost the opposite of
what about encrypted email. I think that the thing we need to figure out is the key exchange.
If we can solve key exchange, solve. If we can have a realistic, widely trusted solution for key
exchange, that's going to improve not just email, but many, many other technologies. And I think that
that's a place that the industry needs to keep working. And there is work going on there.
And then as for email, the main issue becomes, how do you communicate emails server to server
in a way that they can communicate with one another and understand it's an email and know
how to route it? And the two answers to that are you use SMTP and you send a message that is
encrypted, but has enough information to be delivered. And the other answer is you replace
SMTP. And they're both bad answers, because SMTP is not a great solution for end-to-end encrypted
communication. It can be made better, but you need to make a lot of constraints on how it's currently
permitted to work, on how much technical nonsense you want to get into. And replacing SMTP is a great
solution, except for the part where you build a new system, get everybody to agree on it, and widely
deploy it, which we haven't managed to do that for 50 years. Yeah. So if someone is a fast mail
customer, but they want end to end encryption, what are their options? I assume they can still
use PGP manually. Absolutely. Yeah. So they can use PGP, they can use S-MIME. Both of these are
pretty tried and true systems. I shouldn't say recently, I can't recall how long it's been,
but I was a really ride or die Mutt user for a long time.
Mutt is, you're making a face.
Yeah, I don't know.
Mutt is, I would say, the last great console-based mail client.
I love Mutt intensely.
Maybe some other time you can ask me about it.
I mean, I'll talk about it as much as you want, but I'm guessing you don't want to hear it.
People probably don't know what it is.
Well, when I first started using email, the clients of the day were mostly Pine and Elm.
Both of these ran in your Unix terminal.
You could use Outlook Express.
I think Outlook Express was maybe brand new at the time.
And there was a few other things.
But most of us were using text.
And Mutt was sort of the next generation email client.
It ran in your terminal window.
And it was extremely customizable and pretty programmable.
It didn't have a programming language built into it, but it had a lot of automation points.
And so everybody who used MUT used MUT a different way.
And you could see 10 people at terminals working and not know they were all running the same thing.
They're all running MUT, but you can't tell.
And I used OpenPGP.
I signed every message that I sent.
I encrypted some of the messages I sent, and it was painless.
It just worked.
You hit E, and the message was encrypted.
It was sent, and the other person would receive it.
And if they were using a client that understood OpenPGP, they'd get a little lock or a little whatever sigil or, in my case, a little blue bar of text saying signature verified, here's the key ID.
All that stuff works because one of our values is to be a good Internet citizen.
Being a good Internet citizen, it means that we support the protocols that the Internet has agreed should work for email.
We don't support every single email RFC, but I'll tell you what, we support a lot of them.
And the goodness for OpenPGP is you don't actually have to support that much special stuff for OpenPGP to work through your server.
Just the clients need to support it.
Anybody can do that.
That's probably the first thing I would suggest.
But that said, I haven't personally used OpenPGP outside of Mutt almost ever.
Other clients like MacMail and AlkExpress, they tend to have built-in support for S-MIME.
And the kind of the big interesting difference between those two systems is that in OpenPGP,
nobody is really in charge of the trust of your keys.
So you make a key and you show it to someone.
Maybe you show them your passport.
You give them a blood sample and they're like, OK, I'm going to trust this.
And then you can sign it.
And anybody who trusts you will trust their key.
And you get this big web of trust.
And the web of trust is a really cool idea, sort of an early Internet, like we're all cowboys
on the cyberspace kind of idea.
The problem is it kind of sucks for scaling automatically and people just knowing how to use it.
So you get a new key and like, do you trust this key?
And, you know, everybody clicks yes on every dialogue that pops up.
So it doesn't have a great trust model.
Smime is the other way.
Smime is like your web browser having a certification authority that signs it, which means if you want a key for signing your email, you've got to find someone who is willing to issue you that key.
And then they sign it.
But now everything's trusted automatically.
Nobody's doing that for people's email addresses.
There's no let's encrypt for S-MIME certificates.
And one of the reasons is that most mail clients are kind of crummy when it comes to how do you install a certificate and how do you use it.
It's a bootstrapping problem.
So this is, again, I'm sorry, I keep digressing, but that's the way I am.
When you ask about what do I suggest, yeah, I think that OpenPGP and S-MIME both have their place for adding this to email.
But you face a lot of problems.
And then the next option, you put it in the video, and I thought it was a little funny, but I think it's true, is you use email to establish how will you switch to a secure channel.
Which is what you guys have on your website, too.
Good. Well, good. I'm glad it's there. I didn't know it was there, but I'm glad we're consistent.
Yeah, if email is not going to give you end-to-end encryption or it's going to give it to you through, like, snake oil of, well, here's a certificate that you can trust for absolutely no reason.
Upgrade is something that you think you can trust.
I use Signal.
I don't worry too much about this kind of encryption person-to-person,
but I find Signal to have been largely reliable for my needs.
And, of course, there's a lot of other technology people use for that.
Yeah.
Yeah, no, I think the specific web page, if I remember correctly,
it's been a couple months at this point since I was researching for that video,
but I think it was like why we don't do end-to-end encryption,
and it pretty much says one of the reasons is there's just better tools than email.
Use Signal.
Yeah.
And I think everyone would agree with that.
I think even Proton said that in the past before when people were criticizing some of the privacy and security differences between them and things that could be better.
And they're like, well, we're making email better.
We're not trying to beat signal through email.
You talked a little bit about clients.
Does FastMill do native clients or are you guys pretty much web first?
I know you have the mobile clients, but do you have any native desktop clients?
We don't publish a native desktop client. And when we publish a native desktop client someday, it's going to be like the mobile client. It's going to be you are getting a web app that has been encased in a native frame and wired up through that to the native facilities you want.
right? Real desktop notifications, access through certain native API systems, you can't get over the
web API. I think that'll be great. I think that a lot of services work that way now. I don't,
I think that, I think that often people say, well, there's no native app, there's only the web,
and it's kind of disappointing. And you're like, but I wanted a native app. And I've had the
disappointment too. I don't think, I don't think FastMail is going to provide that experience.
You know, I've said a couple of times, I think we shoot for like extremely highly polished interface.
And I think it's going to feel really good.
I don't I think that it's it's just going to work out to be.
This is actually what I wanted.
It's I basically wanted the fast mill interface.
If we didn't do that, the amount of effort required to to say, how do we make a native application that is really native?
Right. Built in the native toolkits, some portable interface that we can implement everywhere because we already have that into the Web.
the amount of effort would be enormous. So I don't think that you're going to see a Windows 11
native app written exactly for Windows 11. You know, someday you're going to be able to say,
give me the FastMill Windows 11 app, and it's going to be a beautiful web interface,
just like your mobile app. Nobody really complains about the mobile app being a web view,
unless it's to say, why doesn't it do offline? And the good news is we do offline as of a couple
weeks ago in production. So hopefully that'll go great. Yeah. And then when it comes to
integrations with things like email aliasing and kind of the other features, the way that I was,
again, it's really hard to review things because reviews are tough on my end because I want to ask
questions for things to make sure they're accurate. But I also don't want to ask too many questions
because then I'm injecting the company's opinion into a review.
So my assessment, and I'm wondering if this is accurate, actually,
my assessment in that comparison video is that you guys rely a bit more on integrations with third parties.
You guys have your email aliasing that integrates with other services.
I believe you integrate with 1Password.
But you're not out there to build your own password manager either.
Do you think that's fair?
How do you kind of envision FastMail integrating with people's overall workflows?
Yeah, I think that's a reasonable assessment.
I think there's a fine line because when we provide points of integration, what we like to do is to say, how is this meant to work?
What is the normal way to integrate with something like this?
And so that's stuff like, well, we offer CalDAV.
And if we want to do a calendar integration with a service, we will work with them.
We worked with YouCanBookMe, for example, on integrating with their scheduling system.
And it was largely, here's how our calendar implementation works.
How do we figure out what either side of us is not doing as well as we could to the standard to make it work as effectively as we can?
Because, of course, if we fix our implementation of the standards, it benefits everybody.
If you can synchronize your full calendar set more effectively from FastMail, sure, it helps our partner, but then it helps every other partner.
Sometimes that doesn't exist.
Masked emails, the feature that we've developed that together with 1Password, we wanted a means where 1Password could say,
I'm signing up for a new service.
Don't just give me a new password.
Give me a new username.
And it would sort of immediately go to your FastMail account, make that username, and drop it into 1Password.
One password sure as heck did not want to run an email service to offer this feature.
And I think we've never had any interest in doing anything like a password manager.
So it was obvious to do something and we needed an API. So we wrote one. And that's the sort of
thing we would probably do in the future with other kinds of features we want to add.
Fastmail is built on a protocol called JMAP, which we developed and it's now
It's got an internet standard document, and it's meant to be very extensible for features like that.
Masked emails, for example, are built into JMAP.
But the difficulty is some features don't have anything like that.
You want to talk about spreadsheets, right?
Well, when are you going to have a spreadsheet in the file system?
Well, there's no standard, and then I invoke the web spreadsheet editor.
So you say, well, you could integrate with Microsoft Office.
You could integrate with CollabSuite, all these other things.
They're not standard. And you either lock yourself into somebody's proprietary API, which you then have to chase year after year as it as it changes, probably for good reason.
Or you have to implement four or five different APIs to interact with systems that are all different, but in the same space.
That's the kind of place we are looking at our Dropbox integration, where you want to integrate with Dropbox and Google Drive and Microsoft OneDrive.
They all have different APIs, even though they're all file systems.
So every time we look at integrating with a third-party system, the first question is, can we do it with open standards?
Because that keeps the internet open.
And if we can't do it, can we, first of all, we can't do it, is it worth doing?
And can we do it by making a standard?
Even if it's only a draft, we might publish later.
And if we can't do that, how do we prevent it from being an ongoing maintenance cost more than it's worth?
Because most people don't use most features.
So every feature has to really pat a punch.
Got it. Okay. And I want to ask more about JMAP. But before that, you've mentioned good internet
citizens quite a bit. How do you feel that you guys are good citizens? I know you've already
maybe touched on a few of those things, but if you could summarize what you think you guys do,
that makes you good citizens. I'm so tempted to go see what we've written on the webpage,
but I won't because it would be cheating. I think that there's a bunch of things. What I would love
to hear, maybe I should do, is ask our staff what their various answers would be from the
different departments. But I can tell you what I think. I think that for me, the internet is a
really amazing place. It doesn't really have centralized governance. It doesn't really have
a central authority for almost anything, and certainly not the things that we use most directly.
And that lets the internet grow and evolve and invite new people into it really freely.
And the downside of that is that, A, it means it's sort of ripe for takeover by anybody who
can overwhelm the value of its open standards, which is unfortunately easy because open standards
tend to be slow and private companies can move quickly.
And it also means that without a central moderating authority, on one hand, nobody is there to tell you that you are too weird to be allowed to talk in public.
But also no one is really there to tell you that you are too hateful to be allowed to talk in public.
So everything in my mind about being a good internet citizen is about understanding the systems that you're building socially and technically and how they moderate people's life experience, whether that's communicating with other people, whether it's communicating with strangers, whether it's how they live their life or their multiple lives.
They have several different personalities, several different identities or contexts that they experience life in.
Giving people the tools to manage their life or the parts of their lives in ways that empower
them and that let them separate the concerns of their life is really important.
And building a system where those tools can be effective, right?
Not where there's one central authority who knows all your secrets, but where you can isolate
the parts of your life and have them work together in a federated way where you might as well
be two strangers communicating with yourself if you want to be.
To me, that's how we make the Internet a good place.
And the other part of it is not being a dick.
Don't be an asshole.
Like, that's really, really important.
And that's something that it's hard to do on a corporate level.
Of course, we try not to be terrible, but that's a personal responsibility.
Yeah, so I think it's really easy to hear that.
And I think a lot of people on the Internet have become disillusioned with what bad things look like.
And we can look back in history to even compare because Microsoft in a day was being held legally liable for doing things that look like nothing nowadays.
Right. Like pairing their own browser with an operating system.
Right. That was that was seen as horrendous just, what, 30 years ago now.
But nowadays it's like they do all this crazy stuff. Everyone gets away with it.
So what does a bad citizen look like?
What is, if someone's listening to this for the first time, and of course, we don't need
to like single out anybody here, but how do you kind of, if someone doesn't really pay
attention to tech, tech for them is just, you know, they just plug in something in their
GPS in their car.
It's how they get from point A to point B.
They're not thinking about it.
How would they think a bit more critically about what a bad citizen looks like if they
don't really notice anything wrong in their day-to-day life?
Yeah.
Well, first I will plug our completed podcast, off the air podcast that we did for a couple of seasons called Digital Citizen.
And it is largely about this question of what does it look like to be a responsible Internet citizen.
But I'm not just I'll keep going because I'm not going to ask everybody to hit pause and go listen to, you know, 26 episodes or whatever.
I think that one of the most important things for people to do is to pay attention.
And that's easy advice to give.
But early on in this conversation, I said that a big selector for people who might use
Fastmail is people who even think about what email would they use.
And I was talking then sort of in a product marketing kind of sense, right?
If you stop and think about what do you want out of your email, you know, is it fast?
Is it private?
Is it secret?
Whatever.
But on the other hand, you should be thinking about those things not just for your product satisfaction, but for the way it impacts your life and the way you experience the Internet.
And, you know, let's get real.
The Internet is a part of the fabric of everyday life.
So the way you experience the Internet is the same way that you experience Broad Street.
It's the same thing.
And if you want to understand the impact that the tools you use, that the society that you're part of, that the ecosystems you're using impact you, you have to stop and think about them all.
And it's not necessarily an easy or a super reasonable thing to be asked to do, but it's also, I think, sort of the only way to do it.
You know, at best, you could find one really trusted source and outsource all your decisions to that.
But like, first off, you won't find them.
And secondly, once they become that influential, let's see how long they remain super trustworthy.
So I think the thing to think about is where are you spending your time?
Where are you spending your talents?
Where are you spending your cash?
And are you putting it into places that put aside are good for the whole world?
Although I hope people think about that.
Are they good for you, right?
if you're spending five hours a day, you know, doom scrolling on one of the infinite scrolling
apps, is that good for you? Are you thinking about it? How does it affect your friendships
and so on? I guess it's a, it's always feels like a disappointing answer because
I'll digress one little bit more than I'll stop. Many years ago, I lost a lot of weight
and my coworkers, I wanted to buy new clothes. So I came in now I looked like I lost the weight
because my clothes fit. And a bunch of coworkers that week asked me, how'd you do it? And I said,
exercise, and I ate less. And every time I said that, they would say, oh, they all wanted me to
say, I just ate grapefruit every morning. Cold bath plunges, whatever the new trend is.
You just do one thing and it's going to, you know, one quick trick. There's no one quick trick
to have a better internet life. You have to pay attention. You have to think about it. And I would
suggest that the payoff is worth it. But I'm the guy who chose to work for 20 years at a company
founded on the idea that the payoff of being a good internet citizen is worth it. So you can decide
whether that makes me more or less credible in this case. Yeah, and it's interesting. I mean,
it ties in. It's nice to see some things get into the public spotlight. The whole removal of Google's
don't be evil statement ties into this. And I know they just say, yeah, it might be a legal thing.
we can't like legally be held to that, whatever they say.
But the fact that was removed, I think it does make people realize like we've removed
this core identity of trying to be the best people on the internet.
And I know they still claim to be, and that's something that they try to keep that image there.
But I actually like don't be evil as just an overall motto to stick to for most companies.
Yeah.
And for every person, right?
And if every person was able to seriously keep that as their personal motto, you'd like to think that the companies would naturally follow.
But it's hard.
And also people disagree on where the boundary is.
Yeah.
I want to go into a few more technical pieces about FastMail now.
And so this is going to include things like JMAP.
What exactly is open source?
Because I didn't think you guys were open source, but it sounds like you might have some aspects that are open source.
So I want to get into the nitty gritty there.
I want to get into jurisdiction, phone number registration, which I know is something I mentioned,
and I was hoping to ask a bit more about that.
And then kind of we'll start with those kind of things.
So I want to start with JMAP.
Do you want to explain for anyone who doesn't know how emails work, what regular technology
looks like, and then what JMAP is and why you have your own protocol?
Yes, I would like nothing more than to talk about JMAP.
So the two most common protocols people use for their email these days are SMTP and IMAP.
There's a bunch of other protocols.
I'm going to talk about those two really briefly.
First thing I'll say is SMTP comes from the 70s and IMAP comes, I think, from the 89.
It's from like the late 80s, maybe 1990.
But they're old.
They're old protocols.
And there's nothing wrong with the protocol being old, but it tends to mean it's, you know,
it's like reading, I'll be really complimentary and say it's like reading Shakespeare. Maybe it is
wonderful and beautiful, but you got to put in some effort to understand how the thing works.
And you got to have this whole mental model of like, you know, what exactly does that little
accent mark mean I'm supposed to say this? I don't think it's actually like Shakespeare. I think that
SMTP and IMAP are both kind of dreadful. They're built on a lot of assumptions about the way computers
work, the way that people are going to use their email. And then what we tend to do over time
is add complications to these systems
to cope with the situation of our contemporary problems.
SMTP is used for two things.
It's used for getting email from one server to another.
So if I send you an email,
at some point it's going to leave a FastMail server
and go to a Proton server.
And it's also used usually
for getting email from my computer to my server.
We call that SMTP submission.
So I hit send, it goes through SMTP to my server,
it goes SMTP to your server,
and now it's waiting there for you to read.
Now, Proton's a little weird,
so we're not going to talk about Proton as your end of the example.
Let's say I've convinced you to move to FastMail.
So now you're going to read your mail with IMAP.
IMAP is the other part.
It's the Internet Message Access Protocol.
The idea behind IMAP is your mail is on a server
and you want to access it over the Internet.
So you connect over IMAP and you say things like,
hey, open up this folder, tell me what's new,
get that message. I want to read it. And it's all designed so that all the mail can then be stored
on your computer. So you've connected to IMAP. All your mail is downloaded with IMAP to your computer
where it can be kept in sync with the server efficiently. And then you can read it even if
you go through the Lincoln Tunnel. And all that's great. And the problem statement is still a real
problem. How do you get your mail efficiently, update it, communicate offline? It's just that
The solution for doing it is built for the problems of the 90s with a bunch of bolt-ons.
And also, you have to understand, if you're programming in it, you have to understand how to,
you have to understand all the concepts built into it, which aren't concepts found anywhere else.
And last point, if you are sitting at your computer and you are connected to your IMAP server,
waiting for new mail to come in, you will keep at least one and possibly more than one open connection
to your IMAP server.
This is actually a really interesting point, because open connections are not free.
Every open connection you keep to your server is work being done by both your computer and the server.
That server is probably serving a lot of people.
If you imagine it's a Google IMAP server, it's got a squintillion people connecting to it,
doing huge amounts of work just to keep connections open and stay when new mail came in.
It's designed for a time when these weren't the real problems,
And if you wanted to solve the problem of tell me about new mail, you solved it by adding something weird to IMAP.
So JMAP sort of came about about 10 years ago when we said, what if we just built something new?
What if we built a new protocol designed for today's problems, but backwards compatible?
And one of the authors of IMAP said to us something like, you're dreaming if you think it's ever going to work.
But we decided to continue dreaming and we built this thing.
And the thing we built is JMAP.
It only replaces the IMAP part of this equation.
It doesn't replace server to server.
It does replace sending your mail in from your laptop to the computer.
And there's two important things to talk about.
One is it's just HTTP and JSON.
And if you ever go look at email, email submission, calendars, contacts, which DMAP also handles,
all a bunch of weird protocols like DAV.
It's all a bunch of weird data structures
like vCard and iCalendar.
I mean, I know them pretty well these days,
but they're just a nightmare.
And if you were going to say,
I want to write a couple little tools,
a couple little toys for me to use for my personal data,
because remember, your data belongs to you
and the server is just there to be a steward of your data.
You have to go learn these crazy ancient protocols.
Every programmer these days knows HTTP and Json.
excuse me it's it's how the internet works these days so jmap gives you a way to say i want all
these benefits i want to synchronize my mail offline i want to finish efficient communication
back with the server but i want to do it in a simple way that i can understand and if i need
real-time communication like a real-time update from the server we have ways for doing that now
it's how you get a push notification to your phone right it's a it's a web push those things don't
don't require open network connections,
which means they eliminate
surprisingly large amount of resource usage
in data centers
and make your services a lot more reliable.
They also have a lot of benefits for authentication.
And I'll stop going on about that,
but I really could.
It's really kind of shocking
about how much better,
both in terms of simplicity
and leverage,
JMAP is.
Also, as a programmer,
it's really nice.
It's really nice to work with.
I feel very good about using it.
So to summarize this, so there are essentially two communications.
There's a communication.
If I'm sending an email, there's communication from me to the server of the service that I use.
And then there is server to server.
If the other person is using a different email provider, then it has to go there.
You guys don't modify that second half of the equation because that would probably break the interoperability between you and other people.
unless you found a way to translate protocols between each other or something goofy that I don't understand.
Yeah, we just wouldn't do it.
Yeah.
So you guys are only able to do essentially what's within your own ecosystem for your own customers.
That's right, but yes.
So I'll start with yes.
But the important thing to note is when you say within our ecosystem,
you're correct that we're not changing the way server-to-server works.
But JMAP is a set of Internet standard documents.
So you can go look at RFC 8620, RFC 8621.
Those define the core JMAP specification and JMAP for email.
You can find those documents.
They're published by the Internet Engineering Task Force.
You can download them and you can write software that implements those.
And then you can point that software at Fastmail and it will work.
Great.
And the dream, the further dream, is that more people will build JMAP clients.
And there are some.
You can go on the iOS app store and the Android app store and find some JMAP clients that are not our web UI.
So if you really want that native client that's built in Swift, because that's what you want to run on your iOS phone, you can get one.
And there are other people who have implemented JMAP servers other than the JMAP server that we use.
And so you could take a JMAP client someone else has written and a JMAP server someone else has written and have your own ecosystem still using JMAP.
So that's the big difference in being a walled garden.
We made plans for how to make gardens that would all connect up beautifully.
We published those, and so far it's going pretty well.
Has any other major email provider integrated JMAP?
Well, Thunderbird says that their new product is going to.
That was released pretty recently.
There's a few people who have been doing some larger scale work.
I think Thunderbird's probably the biggest who's made a really clear announcement.
We've spoken with a number of pretty large providers.
And in a lot of ways, the short version of the mega large email providers is they all see the benefit of doing it and are keen to do it.
But there's a chicken and egg problem.
If the Apple iOS client, the number one mail client in the world, does not support JMAP, then what does Google save by implementing it?
On the other hand, if the top four mail clients supported JMAP, all those active server connections to Gmail would have value to Google.
And value to Google here, I mean dollar signs.
It would reduce the amount of CPU.
It would reduce the amount of bandwidth used.
It would have significant changes.
So there are economic forces at play in very complicated ways on the really large things.
I think for me, it's not a big economic scale, but for me, it's always about delighting the developers.
JMAP is a delight to work with.
And so we see people saying, I want to build a really nice JMAP client or a new JMAP server and building these things,
which means we're building up expectations and experience around the system working,
which I think is going to have a long-term effect.
But I would love to see at some point Apple and Google coming out and saying,
we've decided we're both rolling out JMAP next year.
That'd be terrific.
It sounds like it'd be nothing but an improvement.
And I guess that's my next question.
So for a regular person listening to this who's maybe not a tech nerd,
they just log into their email, they just care about the realistic benefits to them.
How does JMAP change their day-to-day life?
Is it faster?
Does it offer any security or privacy benefits?
What can they expect?
- So it is faster.
It's faster, it synchronizes more quickly and more reliably.
It makes a lot of these operations simpler
for both client and servers to implement.
So one of the things that you don't think about a lot
is places where, we started with this standard in 1990
and now we've bolted on a bunch of extensions.
Sometimes the extensions aren't really perfectly designed to work together and they'll allow weird things to happen.
Or in fact, putting aside extensions, IMAP itself has the means to say, I want a message to be in one folder or another.
But the original IMAP does not have a way to say move this email from folder one to folder two.
Instead, you copy it from folder one to folder two and then you delete it from folder one.
I can almost see this because in like the Apple mail client, it says moving.
Like I think it almost describes that in a way because it says, oh, moving and then it deletes.
And it's like, oh, it seems like it's multi-step just to do things.
It can be.
Now there's extensions.
There's extensions for moving atomically.
But there's two problems here.
One is what if your mailbox is full?
You've used all your quota.
Well, you can't copy a message when you're out of space.
So you can't move that message.
And also, what if your connection dies after you have copied it, but before you have deleted it?
These are not big things, but imagine these little things multiplied all throughout the system.
Those kind of problems have largely been carved away in JMAP.
These are issues that we don't want people to see.
What it ends up feeling like is the system just works better.
And we can make a list of the little things that have been improved, but the short version is it just feels rock solid.
Because even if IMAP has extensions for making an atomic move happen, if you have to support every IMAP server out there, the first thing you do is implement copy and delete.
And after you've done that, maybe you don't go back and implement move because the feature seems to work.
Sure, it has a couple edge cases, but it works.
The other question is about security.
there's a number of security cases and some of them are kind of obscure but i'll tell you one
it's not obscure in imap i said earlier if you want to stay connected and you want to listen for
new mail coming in what actually happens is your imap client has connected to the server and you say
i'm going to idle and then it just sits there and everyone's while the server's like i'm still here
and the client's like i'm still here but if there's a new message you can say hey you got a message
and then you fetch the message and you read it and everything is good um if you are on a mobile
handset, right? Your Android device, your iOS device, they don't let you keep an open IMAP
connection. It's antithetical to the way they work, right? They want to be able to kill off
your application whenever they need more resources. So keeping a network connection all the time,
that's out. So what happens instead is some mail clients will, when you sign up, they will take your
OAuth token or they'll take your password and they'll store it securely. I put quotes on, that's
not fair. They store it somehow, hopefully securely in the cloud. And then they have a client that sits
idling on your mailbox in the cloud with your password. And when it sees there's a new message,
they convert that into a push that goes to your phone and tells your phone to get it.
It is totally possible to do that in a way that is very low knowledge, not really zero knowledge,
but it's not zero knowledge. And it's tricky. And it's a lot more effort than saying, yeah,
we just have an IMAP client and sure it could read all your mail, but we won't.
With JMAP, we use standard web push.
Web push is another open standard.
I think it's RFC 8030.
It's somewhere around there.
And you can just say, I want pushes to come to this web push mailbox.
And the server, when it has new mail, will post.
It will make a post to your endpoint and say, there's new mail.
Get it if you want.
Don't if you don't want to.
But that's it.
The connection lasts for, you know, 10 milliseconds.
And with that, your device doesn't need to give extra credentials to anybody, which is
a significant security improvement.
Is this why, and I know this is totally to the wrong audience, I don't even know how many
Gmail users we have who are listening to this.
I'm hoping that the stat is reversed, where maybe 20% of people listening to this use Gmail,
80% don't.
If you try to log into your Google account on your iOS device, like in the settings, and
try to use Gmail inside of Apple Mail, to this day, in 2025, there is no push notification
support.
You don't get push notifications, and that's because I think Google uses IMAP, and Google
doesn't want to host IMAP push notifications for Apple Mail.
They want you to use their native app.
Yeah, I can't speak with a position of authority, but that's my assumption.
Is that because I don't want to...
It's a resource thing?
That's a guess.
I can make a bunch of speculation. So one is, gosh, I'll get technical and you can decide if
you want to delete me babbling. You know, one possibility is that when you are authenticating
with a very large service, you don't usually use a password. Sometimes you will, and Google will
sometimes let you make app-specific passwords. I don't know whether iOS uses those anymore. I would
be shocked. Almost certainly what you have to do when logging your iOS or Android, well, Android's
a special case, logging your iOS device into Google is to enter an OAuth authentication workflow,
where you get brought over to Google and they say, oh, hey, this is your friendly Google web page.
Do you want to allow Apple's mail client to connect? And so then they give you a token,
and you can use that token to authenticate.
Those tokens, you are meant, you should,
it's not a must, but you should
only have one thing using that token at a time.
And what tends to happen is you use the token,
eventually you say, can I get a replacement?
This token is wearing thin.
And their server says, yeah, here's a new token.
Keep using that one.
If two different things ask for a new token,
the server's like, yeah, you're saying,
can I replace token 5? I already replaced token 5. Something is broken. You're messed up. And what
that means is your iOS device can't have a token to talk to Gmail, but Apple can't run a service in
the cloud that's using that OAuth token to idle and send these connections to you. That's one
possibility. And that's a real possibility that affects some services that use OAuth in that way.
The other option with Apple is that Apple doesn't really mess around on questions of privacy and security.
And if you went into Apple's mail team and said, I think that we should run a service in the cloud with access to people's authentication tokens that sits on IMAP idle, they would boo you out of the room very quickly.
So there's at least two strong possibilities.
But as for the facts, I don't know.
Yeah.
Interesting.
And then another Apple question here.
iCloud released a really cool feature, Advanced Data Protection, several years ago now.
I think it's a wonderful feature.
It has enabled end-to-end encryption for so many people who might have never even used it before.
It's super convenient.
People won't even notice a difference if they enable it.
I highly recommend people enable it if they haven't in the Apple ecosystem.
But it excludes calendar, contacts, and email, which all use these technologies you've been talking about today.
Again, this is another thing I'm asking you to comment on on behalf of another company.
But do you have any speculations as to why they did that?
I mean, we can just, you know, guess, I suppose.
Gosh, you know, I'm not really sure I know.
I'm aware of the feature existing.
I haven't used it.
I don't know.
And I don't think I'm even in a good position to guess.
What I would say is if you are curious, and I might do this research myself, but don't wait for me.
If you were curious, what I would do is go read Apple's technical knowledge-based documentation
on their advanced data protection, because Apple's documentation is often good on these topics,
and it may include, here are our motivations and criteria. And if it does, it might be enough
information to figure out why, but I haven't read it, and also the documentation might not exist or
might be bad. But no, fundamentally, I don't know the answer. Okay, cool. Just figured I'd ask.
One other question, I know this is, you mentioned earlier that FastMail would love to do end-to-end encryption if it's feasible and it probably doesn't sacrifice the user experience.
This is a bit more of a hypothetical, so it's not me asking because you did this, that means you do this.
But does JMAP and that tighter integration that's more reliable and stable make it easier to do end-to-end encryption theoretically than IMAP?
Yeah.
I know it doesn't solve the issues of end-to-end encryption, but I'm just kind of curious if it helps.
It's not clear.
I mean, I guess I'd have to think about it a lot more.
There's a couple things to think about.
If you look at how JMAP works, and we've got a YouTube video that's me explaining JMAP versus IMAP somewhere.
If you send it to me by email after, I'll include it.
I'll send you a link.
Yeah.
You can look at JMAP and really, I would say, pretty easily understand what it's doing, which is one of the hallmarks of a nice protocol.
It just makes sense.
And what you'll see is things like email search from whatever and from Henry.
And then you get a response back.
So these emails, you know, 1, 7, 19 and 4 are from Henry.
Well, the problem there is whatever the server that you're talking to actually needs to be able to see the from of the message.
Now, the way that FastMail's offline support works, and I think we have blog posts about the technology.
Actually, I know we do, but I don't recall in depth whether they explain this part.
is that your web browser effectively runs a tiny JMAP server inside of the tab,
and the web client talks to the server in your web browser, which caches data,
and it gets the data by talking to the server.
So when the whole point of IMAP and then JMAP was having an efficient way
to synchronize your data offline, to have a powerful cache and cache management system,
and resynchronize effectively and efficiently, we've done that in multiple levels.
The browser synchronizes from the server and the client, which runs in your web browser, is synchronizing from the server also running in your web browser.
So on one hand, that lets us do offline because it lets us say the worker thread in the browser is going to use the browser storage for storing the cache.
On the other hand, it's a way to say, well, the JMAP server running on FastML side or whatever server side may not have access to the data.
And so if you try to search or like you can only search by date received, that's the only information we have.
We could then transmit to you encrypted data, which your web browser could decrypt, store in its local cache, decrypted, and allow you to search it there.
And in that sense, you would be able to use JMAP.
Any JMAP client that could speak to that would work.
But if that happens to sound familiar, it's because what I'm describing is the Proton IMAP bridge.
right? It's a way of saying, well, the data is all encrypted somewhere else, but we're going to
synchronize it here and then present a interface to it that is a standard protocol. And yeah,
that's fine. Like it's a way of solving this problem, but JMAP would help by letting you use
a very high quality, high efficiency client, but you would need something that was managing the local
decryption of this data. Got it. Open source. So you've mentioned that you guys do some open
source stuff. What is that? Because again, I think I mentioned you guys are entirely open source,
but what does this kind of look like? So the, I think it's, I don't want to be wrong, but I think
the most notable, certainly the largest scale open source work that we do is the Cyrus JMAP server.
So Cyrus is one of the most popular open source IMAP and JMAP servers.
It's originally developed at Carnegie Mellon University, but these days where the IMAP, I'd have to look, I think I looked recently, it was something like 92% of commits in the last 10 years were written by FastMail.
It's an open source server that does at least IMAP, JMAP, CalDAV, CardDAV, some amount of RSS service, NNTP.
I think it might have had LDAP.
It's a real pile of internet standards, some of which I would like to quietly throw into the ocean.
But when you talk to FastMail and you are speaking JMAP to us or you're speaking CalDAV or CardDAV or IMAP, there's a very thin proxy layer that does a little bit of work, but basically you're talking to Cyrus and all of that is open source.
That's the team that I work with the most, that team I'm talking about how do we deliver what FastMail needs and how do we make all of that work as readily available to open source users as we can.
I would say largely all of the big features of our email calendars and contacts are available on open source.
I'd probably have to draw a diagram to figure out just what isn't.
Our webmail is not open source, although there is a stripped down version of it that you can find on GitHub.
I'm afraid I don't remember where that we kind of offer as a way to test your JMAP implementation.
Because, of course, the web client is just a JMAP client that runs in your browser.
We've got a lot of FastMail is written in Perl, and we've published quite a lot of our software to
the comprehensive Perl Archive Network, which is where you can find open source Perl libraries.
A lot of the email libraries in Perl are written or maintained by FastMail staff.
And Squire, which is our rich text editor in our composer, is a pretty popular library for implementing a rich text editor.
I don't remember anymore who's using it these days, but it's had a number of very notable users in the past.
So we publish a lot of stuff open source.
Not everything, but a lot.
And I think our default position is sort of like, if we think this is going to be a useful library worth maintaining for the public, we'll publish it.
But a lot of what we do is just keeping our servers running.
And tack onto that is our open standards work, which is where I think we're a bit more prolific.
Like I said earlier, when we are developing a new way to do something, we want to do it with open standards.
And that either means, do the existing standards let us do this?
Or is this work going to be of sufficiently high quality that it's worth writing it down as a standard and giving it to the world,
taking it to the engineering task force and say, we think this should be a document that people can use to implement this feature other places.
It's not really the same as open source software, but it's scratching the same itch for me.
Yeah. So what's your general response if somebody is, you know, a hardcore open source advocate and maybe even they exclusively only use open source software and they don't think that your approach really aligns with their values?
And of course, you can just say, well, you don't need to use us. But like, what's your general response to that?
Like, what benefits do you think they're missing out on? Or maybe it doesn't matter in their situation. I'm just kind of curious for that.
Yeah, I think it's tough. I think the short version as well, and you probably shouldn't use FastMail. I think of myself as a pretty strong advocate of open source software when it is appropriate and effective. And there are costs to open sourcing your software. You know, in theory, you can take your software and throw it over the wall, right? Like, here you go, it's our software.
But number one, if you do that, you look like a jerk and maybe you are a jerk.
And number two, you're still pretty likely to be creating costs for yourself.
And the question is largely, it's a question of how do you produce the most benefit for the most people?
And I think that our view is, well, providing people a way to build and run JMAP services and IMAP and so on, but especially JMAP services and JMAP clients in the wild is really valuable and benefits anybody who wants to do it.
And the maintenance cost is something that will really, almost by definition, be shared across the entire JMAP ecosystem.
taking the implementation of the thing that generates the email that says you've been invited to an event and making that open source.
It's real minimal value for anybody outside of FastMail.
And any reported bug that we don't blow off becomes kind of a significant amount of work to take the bug report,
turn it into a test case, integrate the test case, fix the bug, see what else might have been.
Like, it's a huge problem.
And we have to figure out how do we use our person time to the greatest effect.
And that isn't always the greatest effect for FastMail as a business.
It's for FastMail's mission, right?
We are here to make email better.
And that includes the rest of the world.
And we think sometimes the way you do that is not by throwing all the software over the wall.
It's by figuring out how to use our time to the best advantage.
And I should also note here, one of the other things that we value, I think it's not on our
values list, but I can tell you we all value, is being a small company.
At a certain level of scale, your ability to maintain a vision, to maintain levels of quality,
to keep true to your values becomes harder and harder, especially when you are not focused on
how do we create a culture that can and does scale, but rather how do we make a product?
So when we keep our staffing small, it means that open sourcing everything, to me, is kind
of a scary risk.
Right.
And then I do want to touch on that, actually, like your team, where you guys are based and
that kind of stuff shortly.
So is your overall summary, and I guess it's not something that I hear often, not to say
it's not true, it's just that it's not a reason I've heard too much.
So you think the efficiency that you're able to work on the software that you produce for
is better when you don't open source it.
That's one of those cases
where I have to think about what you've said
and decide if it does it exactly
or correctly summarize what I said.
It probably does.
I'm not trying to trip you up.
I'm just trying to find a way to summarize.
I think that's part.
I think that's at least close,
at least part of it.
I also think that fundamentally,
a lot of the time,
it's not so deeply thought through
performed a careful economic analysis. It's, we can look at a piece of work we've done and say,
is it worth open sourcing this? And then you imagine, like, who would use it? How would they
use it? What's the maintenance cost? What does it look like to make that piece of software
carvable out of our existing repository? Right? Because of course, if it's open source,
you probably want that software published in some other repository that is not
the repository inside of FastMail. So you're saying there's overhead
to open sourcing things that you guys like feel like isn't worth or you don't have the
I think that's I would personally say that's my view on it and I wouldn't want to speak for all
the other chiefs but but yeah that's my view okay so I'm trying to find a good way to summarize
I think overhead is totally reasonable I've done a lot I've done a lot of open source work I've run
some some large open source projects and I love it I think it's important I think it it makes the
But man, like when you're the project manager of a large open source project, like your life is overhead.
It's a lot of work.
And you got to figure out, you know, how do you make that work?
Yeah, I've definitely heard that even from, I've seen some interviews with Linus Torvalds and hearing him talk about like managing the Linux kernel is pretty.
Yeah, enormous.
Enormous, incredible.
And I know people, he gets criticized a lot for being, losing his temper in certain situations.
But if I had to navigate the situation that he's in, I don't think I'd have very much patience either.
Yeah, I mean, yes, he is dealing with enormous amounts of change and enormous amounts of expectations.
Those two things, people have expectations and they do or do not want change and often both.
So like it's and they're people and people are hard to deal with.
I love people, but they're hard.
Yeah, especially I think the Internet does make that more challenging, too.
So it's it's layers on layers.
Now, I promise I'm getting down to the last few things here.
One, I guess one concern I would have about the lack of maybe zero knowledge, and it has
It's nothing to do with trust, actually, on the company's behalf, but it's more about like an insider threat or if a hacker infiltrates your guys' system.
So what protections do you guys have in place or assurances to make sure that, like, you know, someone who has, you know, bad intentions can access their emails?
And that's that is I think we tend to view that as our biggest threat model.
Right. Like, how do you prevent that from from being leveraged?
And it's something that we spend a decent amount of time every year talking about and working on improving the issues there.
I don't really, well, first off, I do not have a great list in front of me.
So I'll just fire some things from the hip.
The thing I actually like the best we do is sort of low tech.
And I don't know, I feel very pleased about it.
We have really good customer service.
And when I talk to people about why they should use FastMail, and what I want to say is, let me tell you all about JMAP.
It's so exciting, but, you know, my barber doesn't care about JMAP.
But what I end up saying is, like, well, if you have a problem with getting your Apple Mail to connect, you talk to a human being who will get right back to you.
And if they can't help you, they can shout, you know, 10 meters across the room to me, like one of the foremost people in a position to fix your problem.
And compare that to very large providers, that's a great experience.
But it means that we've got a support team who want to be able to help you solve your problem.
When they do that, they can access your account, I put in scare quotes, because what they actually
get is sort of an interface that looks kind of like your interface with kind of the same
shape.
And like there's 17 messages in a folder, but those messages all say lorem ipsum and the
folders are all foo, right?
And it's like they get an interface where they can see massive structural problems occurring.
But if they want to access your information, you need to positively opt in and say, I am giving access to support.
And this is different than protecting against the person who's gotten into the data center and plugged a keyboard into a server.
But it protects against a lot of, how do I put it, social engineering becomes a lot harder.
access through the support staff who are the people who are very trained in how to understand
social engineering. It's the thing we take very seriously, but also are not looking at every single
step happening at every part of the request, right? They're an attack service. And first off,
we train them really well to understand what's going on there. And secondly, we've built systems
that isolate them from walking into this danger room of user data. User data is toxic. You never
really want to be exposed to it. Apart from that, we do a lot of auditing. So when systems are
accessed, we can always see who's accessed it, what have they done, that gets reviewed. And you
know, we can be like, why were you logged into the Caldab server over here? Oh, well, this bug
number, which you can reference, and that's going to be an explanation there. Those are the things
that I think are most important because they build into the way we work. A culture of access and user
data is bad. The things that you do should be constrained to the systems where you are meant,
the log server, the places you are meant to be doing investigation. I think it's going to take,
it would take a lot of work to get us to be fully a zero trust system. Putting aside the question of
zero knowledge of like, technically do the bytes of your data exist in plain text on a live service.
But it is a problem that we are continually working on because when we talk about your data
being private, we've solved the problem. We don't want to look at your data. There's nothing in it
for us. And the next question is, how do we avoid accidental issues or how do we prevent
external parties from getting some kind of insider access to it. That's an ongoing concern.
Got it. And then for the phone number registration, if I can guess, my guess is it's just an easy way
to prevent spam, and it's a very common onboarding thing. Yeah. There's a couple things.
Yeah. Did you want to say anything about where it came from or where this question comes from?
Because you and I both know it's from your other video.
I don't know what you want to...
Yeah, I mean, it's because...
So I guess some context here, and this is definitely more rare.
So I don't really blame you guys for not accommodating it.
But our community may have this a little bit more than most communities.
I don't really have a regular phone number.
Yep.
I only use VOIP numbers on my phone.
And, you know, this doesn't mean I use just random generated phone numbers.
It's just I have a Google voice number, which is like very nice to use.
It means when I travel internationally, I don't have to deal with international SIMs or
international phone plans.
I'm just data only and I still have my regular phone numbers.
So it's just very convenient.
And but I wasn't able to register for FastMail with any of my numbers.
And I was willing even to like put in a credit card number like I was willing and I was really
happy to accidentally discover the mobile workaround.
Like I was able to register on mobile.
I was able to pay on mobile and it didn't ask me for a phone number when I did that.
And then I'm like, cool, I got in and I was really happy.
Is that on purpose?
It's at least somewhat on purpose.
And I'll tell you some.
The first thing I should say is those issues around sign up and verification are sort of constantly in motion.
Every time you adapt to attackers, their attacks change and you have to keep moving.
And I'll come back to why these attackers even exist in a little bit.
I was a little surprised by the implication that you couldn't just pay to skip phone verification.
That might be a mistake on our part.
It might be a bug.
It might be that the intended behavior changed and I didn't notice the memo.
Like, really possible.
And it might be that there was some, you know, click here to just pay that you missed.
I just don't know which one it is.
Yeah.
But let me start by saying, I don't want to know your phone number.
I don't want to know anybody's phone number who's using FastMail.
The phone number for account verification is like, we'll keep it on file to help you with security to some extent there.
But yeah, as you said, it's a question of reducing fraud.
And letting people verify with a VoIP number does not reduce fraud.
Because the ability of robots to immediately get 10,000 different VoIP numbers for 10 minutes to go through this process is unbelievable.
It's crazy how easily that can happen.
And I really wish we didn't have to do any of it.
What I would like to say is, yeah, you get your trial account.
At the end of the trial account, you pay or you don't.
And in the meantime, what the hell do I care?
The problem is email is a service that you use for talking to other networks.
You don't get a FastMail account only to talk to other FastMail users.
You might, but it's uncommon.
You want to talk to Gmail.
You want to talk to Hotmail.
You want to talk to Proton.
And one of the things some people want to do when they talk to Gmail is to send emails that say,
your Amazon package is delayed.
Click here to find out more and put in your credit card.
Phishing is huge.
There's two ends to it.
One is people who want to send phishing mail, and one is people who want to receive verification emails from other services so they can create a whole bunch of signups, receive these messages, and read them.
So we do things to prevent people from sending or reading mail if something's going on with the account, if it's from an unusual IP, if there's a lot of ifs, there's a big algorithm somewhere in the system.
And it would be really nice if we didn't have to do that.
But the problem isn't just that being a good internet citizen means we don't want people using our platform to send garbage.
It's that the way everybody in email does anti-spam is going to include IP reputation.
So if Google starts getting a thousand phishing messages from one of our IPs, they're going to say, I don't know what's going on over that IP, but I don't want it to mail.
And now this one signup, and it's usually more like 25 signups, blasting out email as fast as they can, has a negative impact on the performance of the mail of everybody else.
We've done a lot of things to isolate that, to contain how it works, but it's never quite going to be enough to fully isolate it.
And one minor tech digression here is we're especially hamstrung because server-to-server email communication is pretty much entirely on IPv4.
So you only have so many IP addresses that you can isolate new signups into.
You can't say, well, all the new signups get their own little tiny niche of IPv6 space, and you can figure out exactly what's going on.
You have to put them on this very, very scarce resource.
So it stinks.
I wish people didn't have to do almost anything to verify, but that would only work if we didn't
have jerks signing up and making life worse for people who definitely are paying.
Yeah, and it's a bummer.
So when I'm asking this question, really, if I'm wrong about being able to bypass that
and I just missed something, I super apologize because that fully addresses my concern.
Because I, you know, Signal asks for a phone number.
People ask why.
Probably very similar reasons.
Proton, people complain, oh, I'm just trying to sign up for a free account, but they make
me put in a valid recovery email and it can't be an alias service.
So people are like, well, it's not even in a fully anonymous sign up anymore.
And it's like, yeah, because that's how you can still have a usable service for people.
So I have no issue with services having ways to verify people are legitimate, that they're there for the right reasons.
And I think it's really good that you guys do that.
I just didn't see the – I was like, I just want to put in my credit card.
So I might have totally missed something, and if that's an honest mistake, I'm very sorry about that.
It could be a problem in our end, too.
I just don't.
So, yeah, that was mainly – I wanted to see if that was intentional or not or if there was a specific reason for that one.
Because, yeah, I don't have a phone number.
even even taking payment is not a great guarantee because the the it seems like the ease with which
people can get access to stolen credit cards that work is uh i mean it's just all bad yeah um but
nobody can't do a trial of an email service if you can't send mail yeah these people seem creative um
it's a bummer too because like you guys don't have to offer a free trial proton doesn't have to have
free plan like like none of these services have to offer these things for free and it's yeah it's
yes i mean it's cool you guys probably get some there's probably been some value you guys have found
where it's like oh when people actually try our service they see how good it is and they're more
likely to subscribe so i'm sure there's that as a big factor as well but you guys don't have to have
a free trial like yeah you could just pay all of it and then no one could even try using it um and i
But we'd still have the same problem.
We'd have the same problem because those payment still gets you access to send.
And it's like, well, and two days later, the charges are reversed when the person figured out that their credit card got stolen.
But by that time, the signup has already sent 24,000, whatever number of messages.
It's just a hard problem.
And the solution to that problem is for people to not be jerks on the Internet.
But there's a lot of motivations for people to be involved in scamming, too.
yeah i believe it um australia that's uh something i've seen the community talk about um
it's mostly in the context of encryption because australia seems to be heading in a very
anti-encryption direction but so is the whole world right now so you know a session the messenger
moved from australia and they changed all the way to switzerland and now switzerland's being
anti-encryption it's very unfortunate for them um so it's maybe less of a thing for you guys
but do you see the Australian jurisdiction having any implication for the privacy and security that
you guys are able to offer your consumers? I think that what we see is people having
concerns about it. And what would be great is having a jurisdiction that was as good as Australia,
plus had lots and lots of things in place to uphold data privacy and so on. And Australia
not have as much regulation around that as some places do. And it has some laws that seem kind of
maybe creepy, but we haven't seen how they're actually going to play out, right? Like if we
look even, if we look at the analysis of things like Cloudact over the years, like it's changed
quite a bit what people think it will or won't do. In practice, I can say that I have never felt
concerned about Australia. We have gotten, you've seen the disclosure numbers, we've gotten very few
I'm looking at it.
I'm looking at it.
A 24, 16 total.
Yeah, very small numbers.
I think that in every case we've seen the details of what's going on and it's, you know, it's not, there's no blanket anything.
There's no give me everything on this person for reasons that you will never know and no one can ever disclose.
We funnel all these requests through Australia.
The Australian legal process we found to be pretty reliable.
It's, you know, it's not a perfect world, but I don't, but when we look at our concerns and our
risks internally, the actual impact of Australian legislation is not incredibly high on our list.
It's a thing that we're aware of that we would like Australia to have different legislation in
a number of places because we think it's the right thing to do. And we think that the laws should be
doing the right thing, but that's different than them having a negative practical impact on anything
that's actually happening. Got it. And so if people want to keep up with that, I mean, I see the data
transparency report on your website. Is that where people can follow that kind of thing? Yeah, that's
what I would suggest. Keep an eye on that. And from time to time, we post blog posts about things
like Cloud Act, Telecommunication Act. It may have been a while since our last one, but you can find
in our blog archive our discussion of our analyses of these and how they're going to play out. Also,
a lot of this stuff is untested as it reflects email or internet providers. So, you know, what
the law can say one thing, and then what does it actually mean? And what would it get enforced?
A lot of that's not clear. Got it. And then, so what's your team look like? Like,
how many of you guys are in Australia? I'm not hearing an Australian accent from you.
No, no. So I'm sitting here in Philadelphia, center city, go birds. And we have an office
here in Philadelphia. About 10 of us. I should know the numbers off the top of my head, but I
don't at this point. Right now, for the next year, year and a half, our CEO is located here. He does
have an Australian accent. Normally, he is back in our world headquarters in Melbourne,
Melbourne, Australia, where we have, I would say, about half of our staff. Again, I don't have the
exact numbers. We're a bit shy of 50 people, I think, at this point. We've got about half of that
in Australia, some here and some in India, where we have a support team. And this works really well
for a couple of reasons. We have on-call. Basically, everybody's awake when they are on-call.
I don't need to be on-call at three in the morning. This is maybe not a big deal for users who don't
care as long as somebody is on call. But, you know, when you work at Fast Mill, we want you to feel like
you come to work if you leave work. And, you know, then you have your own life that you enjoy fully,
which can be hard to do if you can't put away your computer and go to the movies or go to sleep.
So the U.S. team is online during the U.S. day. The Australian team is online during the Australian
day. And the Indian team picks up a lot of the difference or the middle ground between the U.S.
and Australian support teams. So we have someone on support. I don't think 24-7, but we cover a lot
of that. And then we're all on one Slack. We have integrated Zoom meetings. We all interact directly.
There's not really any sort of like, well, that office over there only communicates through its
individual lead. We do also have a couple of remote people in the US and in Europe.
Got it. And yeah, I guess just kind of pivoting to the last few questions I have here,
or more just broad, fast mail questions.
A big thing that's been rising in popularity,
not for me, because all these things are treating like,
you know, it's like the Chanel bags now of email clients,
superhuman, all of these fancy,
like ultra productivity AI things.
It actually seems to have similar,
I don't want to put words in your mouth,
this is a bit extreme.
It has a similar aspect of what you said earlier,
which is being like heavy into productivity and just working for you.
That seems to be a common overlap there.
Are you guys, do you guys already feel like you offer, I've never used any of these.
So this is more of just me like reading these different web services or these email services.
Do you guys see value in that?
Is there a potential integration or something you want to do that kind of mimics those?
Or do you guys feel like you're taking the right approach?
Well, I'm going to start by, start at the end, which is I think we're taking the right approach
because what we're doing is we're offering the standard mechanisms for interacting with email.
And if somebody wanted something like superhuman to exist for fast mail, they would then implement
it either with IMAP or JMAP and it would work everywhere. That's how that should work. That's
how the internet should work. I don't want to say end of story, but like only Google, right?
They don't even... Superhuman is, that's right. And really it's understandable. You know, when I'm
complaining about these like antiquity of IMAP and the email format like yeah it stinks right you're
gonna how much of my brain is wasted remembering things like how do you what are the six ways of
encoding a non-7 bit clean string in email it's a terrible terrible thing yeah it's common too
notion mail same thing I think it's Google only because all these they seem to be nice email clients
but you have to have Gmail to use them I think that the cure for that is JMAP I think that JMAP
switches it from having to learn all these really weird ways of interacting with your data
to learning one or two fairly straightforward ways of interacting with your data. And then you
can interact with any email server that implements JMAP. And implementing JMAP as a bar, something
has to do it. But if you're running a Cyrus mail server at your university, you have JMAP, right?
You just have to turn it on and offer a little bit of a configuration change. If you're running
if you're running an Apache James server, you have a JMAP server.
And there's other options out there.
JMAP gives you push.
It gives you real-time notification.
That's another thing, right?
You talk about these open connections sitting there.
Superhuman doesn't want to have all these open connections sitting around
keeping in touch with your IMAP server.
They want to get told by the server there's a message.
Then they pass it on to your browser or like an event stream.
And there you go, right?
It just works.
They're using Gmail because it's the only way to efficiently implement their product.
JMAP is another way to do it.
It needs market penetration for it to be worth doing that way.
So that's one part of it.
Like, are we doing the right thing?
Yes, they should be targeting JMAP.
Why aren't they?
Because 80% of the world's users have access to the GData API, right?
The end.
Do we want to offer things like that?
I think that when we talk about productivity users, they are part of our user base.
we have a lot of productivity features. The productivity features we offer,
the good news is that you can use only the ones you want or all of the ones you want,
and you can use them in whatever combination you want. And the bad news is you have to figure out
which ones you want to use and in what combination. So when we are adding features, productivity
features, but any features, we have to think about what does this do in combination with every
other feature we're offering, right? We've added, that's more than a checkbox, right? We've added a
whole lot of complexity by adding even like memos we added to email recently. You can put a little
memo on any email you receive telling you what you wanted to say when you eventually reply.
That's, it's a, it's just one little text box, right? But there's a bunch of things to think about
how does that interact? Superhuman and some other products like it sort of start by saying,
we have a bunch of thoughts about how email should work.
That is one unified way of thinking about it.
And you can approach that and you get all this leverage,
but you have to want to pull exactly the lever they've built,
or at least a lever in that general shape.
PassMill's giving more flexibility,
which is great for people who have a lot of opinions.
And for people who don't really know what they want yet,
it's a question of figuring out what's the next feature that we can offer them
to hook them in to wanting to learn about more,
How do we teach them about more of these features?
I think that something like a radical departure from the standard email interface like Superhuman is, I don't think it's real likely.
I think that it would require a lot more investment on people wanting to learn how to use a tool as opposed to get in, use a tool they already understand, but works really well and get out.
Got it. So you're saying that your approach is to offer, you know, a more focused, more polished experience that even has more productivity in something like Gmail.
And you want to offer like the core critical tools that you think most people need.
And then you would hope that if this tool were to exist, it would be utilizing JMAP to integrate well with the tools you offer.
Yeah, I think that's right. I mean, the person to really ask here is our product officer.
In almost all questions like this, I'm like, actually, I'm the weirdo who used Mutt for 20 years.
If we want to know what we do with the product, we ask the guy who really knows everything about it.
So I'm giving you my opinion, but I think it's probably pretty accurate.
Got it.
Yeah, and I think it makes sense.
It's a bummer.
You know, these tools need to be...
It really locks the kind of consumer away, right?
I mean, I don't think Superhuman cares.
I don't know if they still do this, but I heard they interview you.
have to be on boarded. Yeah. And you have to use Google. So you either are a Gmail user or you use
Google workspace for your business. Otherwise you just can't use the service and they don't seem to
care. And that's probably okay. Cause they charge $30 a month for you to use their service. But I
think it would be awesome to have this ultra powerful email client that was meant to be used
with anything. Now, if someone, the answer is yes, but just for clarification, you guys do work with
IMAP. Oh, yeah. That's not clients that don't support JMAP. Absolutely. Okay. And is that because
you just still support IMAP or is it because JMAP is interoperable with IMAP? Does that make sense?
I know what you mean. No, it's because most male clients are IMAP clients. And so what we want,
You meet your customers where they are.
If the data belongs to you, we should permit you the reasonable ways that you would expect to get at your data.
We're just stewards, right?
And if 60% of our users say we want to use iOS mail, you know, my first response might be, it's not that great.
But the next one kind of has to be.
But in matters of taste, the customer is always right.
So we even offer POP.
And pop is the terrible, terrible thing that came before IMAP.
And I dislike it immensely.
But people use it.
And people really want to keep using it.
And so we permit it.
What I would like is not that someday we take away IMAP from people.
It's that someday everybody says IMAP can go now.
And nobody still wants it.
Got it.
I forgot to ask.
Is the reason why FastMail is called FastMail predominantly because of JMAP?
Is that where the speed benefit is found?
Okay, well, okay, so there's two questions there.
One is, is the speed benefit from JMAP?
And the other one is, is it called FastMail because of JMAP?
FastMail was called FastMail way before JMAP existed.
In fact, FastMail was called FastMail before the precursor to JMAP existed.
And it was just called that because it was supposed to be fast.
And if you go back, gosh, I wonder if we published any of the really old screenshots.
If you go back and look at what FastMet looked like in 2002, it looks very 2002.
You know, it doesn't look a whole lot better than many other things that existed, but it
was very fast.
And it was doing all kinds of, I would say, nasty tricks to be fast.
And in 2002, the web was still kind of a baby.
And in fact, I think it went online in 99 or 2000.
And it was still in Australia, right?
So like it was there's still these questions about latency to the rest of the world.
In, you know, 10 years later, I'm going to say around 2014, 2013, 2014,
we introduced something internally called Ajax UI.
And Ajax UI shifted the entire client to live in the browser.
So previously, you know, you'd click on a message and it would tell the server,
I want to see this message, the server would render something and send it back to you and now you get a new page.
So kind of like a traditional web page where clicking on something, got a new rendered page.
A lot of things still work this way.
Anything written in PHP mostly works these days.
Ajax UI said, well, we're going to put an application running in the browser that can go ask the server for information,
add it to its local data storage, and then update the UI in real time using like a model view controller system.
And this was revolutionary.
It really changed how fast mail could work.
It let you be very, very fast by caching data, by updating the user interface as soon as the user clicked a button and before the server had finished responding.
So this really, I think, changed the kind of perceived speed.
It maybe didn't always change the actual speed because the server still had to actually delete the message you clicked delete on.
But you click delete, the message went away.
A little bit later, the server had deleted it.
huge. And then JMAP was us saying, this is really, really good, right? What if we made this available
for the rest of the world? We got to fix all the weird stuff that we did along the way. And then we
took it out to the mailing list to the public and had discussions about how to ship that.
Then the question is, is that why fast mail is so fast now? It's certainly a big part of it.
Part of it is because JMAP is designed to be very efficient, to be very fast.
Part of it is that it can hide some of the work.
So the work happens after you asked for the work.
We assume the work is going to be successful.
And if it's not, you know, you hit delete and the message comes back and you get an error.
Actually, I couldn't delete it.
But that almost never happens.
So it actually feels very, very fast.
But also, there's plenty of other work that we do to keep it fast.
Just before we started this call, I was working on a bug that when you rename your user,
sometimes your old sessions get one error and then start working.
And the bug's not that interesting to anybody but me.
But in fixing it, all of this is like,
well, how do I make sure all of that works without making the user wait?
You don't want to wait while your session is updated.
You want to get back to work and your session is updated
while you're doing other stuff.
J-Map has nothing to do with that.
But what we say here a lot is,
fast is right there in the name.
I think you said it in your video, right?
It's right there in the name.
It's really important to us.
Part of that fast is that when you click something, it happens right away.
And part of that fast is the whole interface is designed to let you get in, do your business, and get out.
And that requires constant attention at sort of every level of operation.
Yeah, and creative engineering, it sounds like, to not just do the...
It is almost hacky in a way, but not in a bad way where it's like instead of just, you know, clicking order of operations,
you're like, well, we can hide this from the user.
We can offload it so it's out of their site.
And I think that's a lot of creativity involved,
probably, in crafting those workflows.
Absolutely.
And engineering is quite good.
I would say it's not a hack in a bad sense.
I don't have anything against a crazy hack.
I perpetrate those regularly.
But the software implementation is quite good.
It's quite easy to work with,
and it hides the complexity in a good way.
The other thing, it's a fun fact while we're on the topic, something else I was dealing with this week, we have this offline support now, and I described it earlier.
You've got your data cached in your browser.
We've reached a point where if you are in Australia, having an offline cache or in your browser cache for all your data, huge win.
Your mail is so much faster.
Here in the U.S., it's not always clear.
Sometimes it is faster to go ask the incredibly beefy server to do some work for you and get the answer.
A full round trip, you know, several hundred miles or however far it's going to go, than it is to let your browser do the work.
Because your laptop and especially the browser storage APIs are so inefficient.
So, like, now we've got to think about things like how do we decide where to send the work, which is a great example of the choices being made between convenience and privacy.
Yeah. Yeah, that's interesting. And I assume, is that something that's user customizable? Can a person say, I want to only do offline?
Yes, you can't say only offline. Right now, if you say you want offline, I think it always works through the proxy. I guess I'd have to go look at some actual, it's complicated.
But generally, if you say, I want offline support, your requests channel through your local proxy.
But if it can't find the data it needs or just to update, it will pull in data from the server.
But it will not at present say, I've determined that you're so close to the server, I'm not going to use your cache and go directly.
It can't really work that way.
Okay.
Yeah, so, you know, who's FastMail for?
What's your kind of ideal avatar to kind of wrap things up?
And what are you guys planning for the future that you're able to share?
Yeah.
Every once in a while, we talk about who our user is, and we've got a bunch of different
archetypes.
And I think what I'll say, when I think about who is using Fastmail, I try to imagine this
sort of very simple baseline of someone who cares a little bit about their email.
Now, I care a lot about email in general and my email specifically, and I have a lot of
customization, a lot of rules, and I want people to have that available. But I just want, I think
that we look at targeting people who kind of at least care a little bit, right? Someone who says,
my email is important, either because if I don't pay attention to it, it becomes a drag,
or because I leverage my email for like, getting stuff done efficiently through my day. And
what next level of features those people need.
They tend to tell us.
And then, you know, we'll get,
people tell us their 50 big problems.
And we're like, well, which of these problems,
can we solve 26 of these problems with one feature?
Right, and then it's like,
now we know what we wanna build next.
I imagine that the product team
has some more clear ideas about this,
but they keep me away from the product
'cause I use them up for so long.
Things we're doing next.
Well, I'll be super short about the things
that excite me the most, which are open standards work.
we're working on polishing up the final forms of JMAP for calendars and JMAP for contacts.
We've offered calendars and contacts over JMAP for quite a while now, but only to our web client.
You couldn't write your own client with them because they've still gone through a standardization process.
That's done. The standards are largely done and dusted.
So now we're getting all the rough edges of our implementation polished off,
which means soon someone could write a JMAP calendar client or a JMAP address book client.
And that'll be, I am excited about that.
The number of users who are probably excited about that, I'm guessing, is under 100.
Another actually bit of standards work that I am very excited about is we have been working
with some people in the ITF, the OAuth group, and the email group on automatic configuration
and a simplified OAuth profile.
What that really means is if you get a mail client that supports these standards, and you
type in, you know, henry@fisher.biz,
it will just say, great, here's OAuth.
It'll just give you a web browser
for whoever provides your email.
You don't need to type in an IMAP server name.
You don't need to select, oh, I'm using Google
from the little dropdown, you know,
little list of providers.
It just makes everything work.
And then you OAuth and everything happens.
This is huge.
The amount of time that support agents,
not just at FastMail, but everywhere,
support agents spend on client configuration issues is enormous. And if that goes away,
because it's replaced by a simple standard that everybody implements, all those support agents are
available for all the other issues, the response time goes way up and everybody feels like,
man, the support of FastMail is so great, or the support of everywhere else. So I'm really excited
about that. It's going to be good for the users. And we talked earlier about Teams work, which is
hopefully going to be happening at some point not too long yeah um that's all really exciting stuff
and i hope to be using fastmail more on my end to play out some of these things um yeah yeah and um
and i i don't know i i'm tempted because i just know that i would enjoy the experience of using
fastmail better and i don't think that's very debatable um if you if you give it a go and you
hit weird things or want advice, you know, drop me a line. I love talking about how email, how I do
my email. Most of the time, it's not a conversation people want to have, but if you're playing around
with it, I'm sitting here. I mean, we got people on here for well over an hour talking about email,
so I think there's a lot, and the passion is there through the screen, and I know you've taught me a
lot about email, and I hope that you've taught others as well here about email and something
that. Where can people find you and or Fastmail if they want to connect with you guys online?
Yeah, well, fastmail.com is us on the web. I think our webpage is pretty good. It lists our
values pretty prominently, which I said was to me a big selling point. It runs you through the
product. And trying a free trial is a great way to see what you think about it. And we have a really
good import tool. So my suggestion for people is sign up, make a free trial, use the import tool
to bring your mail in, and just see what it would be like to have your mail in there. And if you
don't convert the trial, we scrub all the data, we throw it away. I don't want your email on our
server if you're not giving us money. I want to get that the heck off of there as soon as possible.
And in our blog, you will hopefully be seeing some of the exciting stuff that I was saying was
going to be coming uh we've posted some technical stuff we post some stuff about the standards we
work on and we post about the new features um i mean that's about it i'm i'm on mastodon but i
mostly just post nonsense about borderlands like i'm not really talking about email too much there
yeah yeah it's kind of like my mastodon account too um yeah it's it feels nice it's very it's as
quiet and as popular as it needs to be right now i think and i hope it stays that way at least that's
my experience of Mastodon. But yeah, that's all I have on my end. So I want to thank you,
Ricardo, for being here and sharing so much good knowledge. And of course, you can find all the
links that you share down in the description. Great. Well, yeah, thanks for having me. I had
a great time. I got to talk about JMAP and email, so always a good day for me. Great. I want to give
a massive thanks to Ricardo for taking almost two hours of his time to do this interview. And I want
to thank, of course, you all for watching and learning hopefully something new about not just
FastMail, but email as a whole and kind of what is the future of email and also the different
legitimate approaches to email privacy. I am not a FastMail customer or a user, but I still got a
lot of value talking to them, and it's super great to learn about the different approaches that
companies are taking when it comes to this stuff. And if you do want to watch a more thorough deep
dive, we made a whole video that compares FastMail to Tudor to Proton, which I believe Ricardo
overall likes. So I don't think that's too out there to recommend as a next step if you do want
to learn how FastMail compares to something like Proton and Tudup. Teaser, if you use any of the
three, you're still better off than if you're using Gmail or Yahoo or something like this.
So check those out, and I'll see you guys next time on TechLore.