Everything You Need to Know About Email Encryption in 2026
78 points by fanf
78 points by fanf
I found this article frustrating.
To be clear, the author is right, and email is a garbage system for security or privacy. But also, this post gets stuff wrong. Most obviously, transport-layer security is actually widely available as measured strictly by volume, though not widely enough for it to be globally enforceable by default - although for new routing setups, TIL that Google enforces valid(!) TLS by default (since 2020). There's also the smaller detail that the Subject line is not, in fact, used by "humans and software alike" to do threading. Software almost entirely uses In-Reply-To and only sometimes falls back on Subject header matching. I didn't catch anything else definitely wrong, though I could quibble a bit about threat models (but I also didn't look suuuuper hard, just kind of hard).
Again, Soatok is right. There's a lot of correct points here. For example, I started writing up a dispute about how BCC actually might not leak if the adversary doesn't have the right observation position in the network, but then realized that we know that's a dumb assumption. But the errors, particularly the semi-outdated folk wisdom about email TLS, aren't doing the article any favors.
As strugee said quite some technical things are plain wrong here. What was especially frustrating to me is how much politics, espionage and borderline tinfoil-hat-conspiracy is there. I can safely assure you that CIA won't be hunting down furries or nerds of any sorts with the intent to kill just because of encryption.
Anyone that sees your email can effectively prove you sent it
That's kind of the point, isn't it? The very same rationale can be applied as a positive thing, so in a lot of sense it is a matter of how you look at the whole thing.
Overall I agree that gpg/encryption might be bothersome to use in email, just because exchanging keys is kind of pain in the arse, but signing the messages is ok for same reasons as stated as "bad" in the article: I want to know that the email is
a) not faked
b) was not tampered with upon relaying between different servers.
In my opinion/little experience real privacy that Soatok strives here is more or less "unobtainium": the minimalistic/cheap solutions like age or ssh or Signal or whatever need only to strip off the automated scanning or intervening from ad providers. If you have sensitive data to exchange no amount of Signal can help, because if CIA or other agencies want to read or know something they will most certainly will. You'll gladly hand them the encryption data, yubikey and whatever they ask.
I can safely assure you that CIA won't be hunting down furries or nerds of any sorts with the intent to kill just because of encryption.
Cryptography tools aren't only meant to be used by furries and nerds.
What was especially frustrating to me is how much politics, espionage and borderline tinfoil-hat-conspiracy is there. I can safely assure you that CIA won't be hunting down furries or nerds of any sorts with the intent to kill just because of encryption.
One single mention of something the CIA does is such a large amount of tinfoil hat conspiracy as to need to be called out?
Anyone that sees your email can effectively prove you sent it
That's kind of the point, isn't it?
No. The keyword is "anyone". You want the intended recipient to know that you sent it, but preferably no one else should be able to prove that you sent it. Same thing with your point about signing. If you want the whole world to know that you sent something, like say in a public letter or something, regular old signing is good. If you only want the person you're sending the mail to to know that you sent something, signing kinda sucks.
the minimalistic/cheap solutions like age or ssh or Signal or whatever need only to strip off the automated scanning or intervening from ad providers.
Eh?
If you have sensitive data to exchange no amount of Signal can help, because if CIA or other agencies want to read or know something they will most certainly will. You'll gladly hand them the encryption data, yubikey and whatever they ask.
Hunting down individuals to beat their secrets out of them is actually pretty rare. What's common is large scale surveillance. Signal and other such solutions don't protect against $5 wrench crypto analysis, but it does protect against surveillance.
I wouldn't go so far as overestimating the power of intelligence agencies, but things like age don't exactly drop into my workflow. Age despite being able to use ssh keys doesn't support usage of ssh-agent etc etc
Age despite being able to use ssh keys doesn't support usage of ssh-agent etc etc
We need an agent extension for this to work. Filippo is considering this already for yubikey-agent, and I would gladly follow for ssh-tpm-agent. https://github.com/FiloSottile/yubikey-agent/issues/165
There was also someone that proposed something in a PR a few months back, but I'm not sure if it should be a separate project or part of age upstream.
Age despite being able to use ssh keys doesn't support usage of ssh-agent etc etc
Age's SSH key support is a bit of a hack. It's basically fine, but it involves taking your private key and converting it from being an Ed25519 key into being an X25519 key, which isn't something you can do with SSH agent. Personally I just use the yubikey addon for Age when I don't want key files lying around.
Awkwardly for age, the ssh agent supports basically one fixed high-level cryptographic operation: it stores your private keys and acts as a signing oracle. age uses stunt cryptography to make ssh keys work safely for encryption, but the ssh agent doesn’t know about the magic so isn’t able to help.
Stunt cryptography?
Hmm, I thought age-encryption had some documentation on how it uses ssh keys, but now I can’t find it. Maybe @filosottile can provide a link that’s more official than an old blog post…
Part of what it does is similar to this arcane trickery: https://doc.libsodium.org/doc/advanced/ed25519-curve25519
That's kind of the point, isn't it? The very same rationale can be applied as a positive thing, so in a lot of sense it is a matter of how you look at the whole thing.
I think this argument is too rarely seen in discussions about the problems of e-mail communication. When one for a moment foregoes the “you are being eyeballed by a state actor” setting and turns to the mundane problems of many people below that level, questions like “Was this contract offer / accept actually sent by the person / company who is on the From line”? I know this setting is not at all so much technically interesting or challenging, but I do think it has quite a bit more applications (in shear numbers) than trying to fight a state actor. Fighting fraud is a laudable goal as well.
questions like “Was this contract offer / accept actually sent by the person / company who is on the From line”?
DKIM kind of does that already, although because it's been politically inconvenient for various groups I think there's a bit of a push to publish expired DKIM secret keys.
The article went heavily into the privacy part of things, but for me, my main concern with e-mail is authenticity. I sign all my e-mails with S/MIME (using a class 2 certificate linked to my name that I also use for document signing) and use SPF and DKIM combined with DMARC, TLSRPTv1 and MTA-STS to get the most out of it.
S/MIME also has much better software support, and works much more smoothly than PGP. If one sends me a signed S/MIME message, my mail client (Claws Mail) automatically adds their key to the store, and signs any subsequent mails. Sure, one leaks metadata (especially the 'Subject' field) when encrypting, but with MTA-STS you at least get partial protection from large-scale sniffers.
With all of these aspects, it becomes nearly impossible for a spammer or imposter to forge e-mails in my name. If you need more privacy, and that's where I agree with the author, e-mail is not the way to go.
with MTA-STS you at least get partial protection from large-scale sniffers
Do any MTAs enforce STS by default? Last time I looked around, I couldn't find any that did, but it's been a minute, and it was a hard topic (for me) to find much documentation which covered it directly.
Actually there are more and more. This is why I added TLSRPTv1 to my mail setup, which basically requests MTAs to send you reports on their use of encrypted transmission, and I get a lot of them.
Hey, have you found that S/MIME is a worthwhile investment? It seems, relatively, expensive for something that most people aren't going to be looking for. I understand in a business situation that it could be extremely useful, especially if you're dealing with financials or other sensitive information. However, as an individual, wouldn't GNUPG/PGP be a sane(r) alternative?
Thanks
Thank you for this interesting thought! I found S/MIME to be 100% worthwhile, especially as it's not only about encryption, but authentication. Only very few people send encrypted mails, that's true, and I don't either. But when I send a signed mail, it's very prominently displayed that the mail is signed by me, giving it further validity. Especially given mail is far from 'watertight', it gives my mails more credibility and slightly improves the deliverability, as well.
When you buy a S/MIME certificate, you can also opt for one that you can also use for document signing. Class 2 signatures are legally binding in Germany as it's linked to my name, and I am constantly using my S/MIME certificate to sign documents, and it's universally accepted. Same applies to code signing in git, which I also do with it.
I have used PGP for years, also for code signing, and back in 2015 you could still believe that it could really pull through, but I kind of lost hope. You can really tell that key signing parties have died down massively. Univeral trust needs authorities, that's why I go with S/MIME.
What are your thoughts on this?
Mostly, I've lost the confidence that any sort of built-in encryption or signature systems will work for email outside of S/MIME because there isn't a large enough onus to make it happen. I used to sign my emails with GNUPG, but stopped because my wife didn't like the extra garbage, and when I used S/MIME with that, it ended up sometimes showing as an attachment, which ended up being more confusing.
While I would love to use something that validates my identity, especially in this age of AI reproductions, I find that ~$72/USD a year is a bit steep for something that may or may not make a difference in my personal life. Maybe there are cheaper providers out there, but a quick search showed pretty much the same price range. It's not prohibitively expensive, but I would have to have a good reason to justify spending that much on what, effectively, boils down to a "blue check mark" for email (if that makes sense).
You hit the nail on the head, both in terms of the software ecosystem, which is very polished for S/MIME given its extensive corporate use, but also the prohibition in terms of cost.
72 US dollars per year is expensive, though! I only pay around 39€ for my certificate, which is still a lot. However, I find so much use with it that I consider the price to be warranted. You can also get one with two year runtimes for 69€, reducing the yearly cost to roughly 35€.
I did find cheaper alternatives, so it's back to being something I'll consider. Validation of digital identities is getting to be a much more important topic. While I'm an internet "nobody," I still don't like being replicated or impersonated by anyone or thing.
Thanks for putting this option back in my view for helping with that task.
If email is no good, what should we use? Signal, and nothing else, according the blog's author. I don't want to use Signal, but according to them there is no solution at all for me, as stated in this other blog post:
Now, there exists a minority of extremely technical computer user for which Signal is a nonstarter (because you need a smartphone and valid phone number to enroll in the first place). Because those people are generally not the highest priority of cryptographers (who are commonly focused on the privacy of common folk–including people in poor and developing countries where smartphones are more common than desktop computers), there presently isn’t really a good recommendation for private messaging that meets their constraints.
I find this rebuttal quite light and partly dishonest. First, it conflates smartphones (which are "computers" too) and mainstream mobile OSes (which Signal requires). But mostly, it does not even mention many other reasons to dislike Signal: digital sovereignty, decentralisation, community governance (as opposed to top-down "plebeians trust me"), hackability/tinkerability, Signal org and servers being mostly US-based, 7-figures CEO salary (there are probably other reasons too, this is just out of the top of my head).
Despite being an open protocol, email is (in practice) an oligopoly.
Then pitches a full-centralized service, Signal, as usual in these posts.
I think that the article does correctly express the consensus of the cryptography community, however frustrating that is. And believe me, I find it extremely frustrating.
As usual, this is a semi-disguised ad for Soatok's favorite product: Signal, which you should use for all comms according to them.
The fuck are you talking about? Soatok does not, in fact, think you should use Signal for all comms. He does think that almost everything except Signal has basically useless E2EE, which is why he's working to bring E2EE to the Fediverse, to increase people's options...
But mostly, it does not even mention many other reasons to dislike Signal: digital sovereignty, decentralisation, community governance (as opposed to top-down "plebeians trust me"), hackability/tinkerability, Signal org and servers being mostly US-based, 7-figures CEO salary (there are probably other reasons too, this is just out of the top of my head).
None of these reasons to dislike Signal actually impact whether it does its job correctly, nor whether other possible solutions actually work. So the exact same thing can be said there: if those are your constraints, there is no good solution.
Soatok does not, in fact, think you should use Signal for all comms
I wouldn't go as far as trying to guess what he thinks, but if E2EE/cryptography is the most important thing and if…
everything except Signal has basically useless E2EE
…then it does not sound very much different than saying that only Signal should be used. Fair enough, I should have said "for all private comms".
bring E2EE to the Fediverse
Is this about instant messaging using activitypub? I heard something about that, I'm a bit concerned that reinventing the instant messaging wheel once again is not going to help us get away from the techno-surveillance hell we're in faster, but I'll be happy if I'm wrong. Also, obviously, everybody is free to work on whatever they want, and diversity is good, so I hope Soatok has fun doing that.
None of these reasons to dislike Signal actually impact whether it does its job correctly
I don't think I have said anything about Signal doing its job incorrectly, did I?
nor whether other possible solutions actually work
If you look at that other blog post I linked, section "Private Messaging" it precisely says that we have to use Signal and that everything else is shit.
So the exact same thing can be said there: if those are your constraints, there is no good solution.
These constraints are more important to me than having the best E2EE implementation, which I think falls in the trap that this XKCD about "security" summarizes best. There is definitely a good solution for me, I have been using it for many years, it brings me nerdy joy, does not cost me much, and my family and close friends adopted it.
Don't worry nicoco, every time anyone says anything even mildly critical of Signal, to the point where they simply suggest it shouldn't be the default recommendation, a lot of aggressive and weirdly emotional responses appear, along with downvotes.
I'll note that the parent's opening words were "The fuck are you talking about?" which clearly meets the "unkind" flag criterion, yet somehow they've got more votes than you. That's not an accident.
There's a pattern here that's hard to ignore: people get extraordinarily defensive about Signal in a way that doesn't happen with other technical tools (even rust zealots wouldn't go in so hard). Whether it's coordinated or just emergent behaviour from true believers, the effect is the same.. alternative messengers get downplayed, criticisms get dismissed with hostility rather than technical arguments, and site rules get violated with impunity when defending Signal. People cannot be told that the trust relationship to the organisation is effectively the same.
You've raised legitimate concerns about centralisation, jurisdiction, digital sovereignty, and governance. The response wasn't to engage with those points; it was to attack you for daring to suggest Signal isn't the only answer. That's not how technical discussions are supposed to work.
Personally, I don't inherently trust any single centralised service, Signal included. I've been watching these discussions rage across the orange site and elsewhere, and it's increasingly strange how emotional people get the moment you lean towards not recommending it. The trust relationship with a US-based centralised service isn't meaningfully different from other centralised services, yet Signal gets treated as if it's in a category of its own.
If Signal's technical merits are so overwhelming, why does defending it require so much hostility?
EDIT: of course this has been flagged too.
There's a pattern here that's hard to ignore: people get extraordinarily defensive about Signal in a way that doesn't happen with other technical tools
This is probably because the overwhelming majority of criticisms of Signal fall into one of two categories:
I don't recommend Signal because it's perfect. There are a lot of legitimate reasons to criticise Signal but very few of the complaints ever engage in them.
For example, your post contains the lazy 'centralised is bad' complaint. Sure, I agree. But centralised comes with advantages in terms of anonymity-set size and in terms of resistance to leaking the shape of the connection graph to passive monitoring. SimpleX (I think?) is about the only alternative that even acknowledges that these are real problems that a federated or decentralised alternative and I haven't had a sufficiently detailed look at their protocol to be confident that they address the issues (but I am 100% convinced that no one has addressed them accidentally, so if a design doesn't think about them then it definitely doesn't).
But centralised comes with advantages in terms of anonymity-set size and in terms of resistance to leaking the shape of the connection graph to passive monitoring.
How does that work exactly? If the federated servers speak to each other over an encrypted connection, all you really should get to see is that "someone" on server X is talking to "someone" on server Y, by virtue of there even being a connection in the first place, right? And that only if you can observe the connections between these services. If you assume a compromised server, then yes, you can see person with handle X is talking to person with handle Y, but only for persons using said compromised server. With a single centralized server, the problem is way worse.
If the federated servers speak to each other over an encrypted connection, all you really should get to see is that "someone" on server X is talking to "someone" on server Y, by virtue of there even being a connection in the first place, right?
Yes. But I can also see messages going in and out of at least one server, so correlations let you see which user (or, at least, which IP) is talking to the other remote server. And, if that server has a small number of users, knowing that you're talking to someone on that server is sufficient. And this is often a problem when people want to create a new server for a specific set of users: knowing that you're talking to someone on the 'Amazon Union Organisers' server may be sufficient to cause real-world harm.
If you assume a compromised server, then yes, you can see person with handle X is talking to person with handle Y,
That's the other problem with federation (though not necessarily with decentralisation, if you do some onion-routing things). You have to think about what happens in the presence of one actively malicious server. In a centralised case, that's a binary choice: if one server is compromised, the entire network is compromised, but you can design the protocol to hide most of the important metadata from the server. In the federated case, you have to expose some of the routing information to the servers, how do you expose it in a way that doesn't allow data collection?
How does that work exactly? If the federated servers speak to each other over an encrypted connection, all you really should get to see is that "someone" on server X is talking to "someone" on server Y, by virtue of there even being a connection in the first place, right?
Server X has 1000 people on it. Server Y has 2.
Your k-anonymity is 2.
With Signal, there are millions of users. You cannot reduce the k-anonymity down to single digits.
EDIT: I cannot reply so I will edit instead.
"Your" meaning the communication between server X and server Y.
Further, if you passively monitor the timing of behaviors and combine that with other metadata, you can usually uniquely identify each person on each server with such a small anonymity set. Even with 1000 to start with.
Also, if initial handshakes (the first message in an encrypted comm) have a different shape than subsequent messages, and you know who already follows/interacts publicly with who, you can usually narrow it down further.
Is anonymity the only goal? I thought many wanted to be in control of where their personal data/metadata is stored or at least know the server operator as well as not being beholden to some tech lord’s whims as to whether the service stays online or not.
Your k-anonymity is 2.
"Your" meaning, the persons on server Y, right? That doesn't affect the persons on server X, and it also doesn't explain @david_chisnall's shape of connection graph leakage to passive monitoring.
Don't worry nicoco, every time anyone says anything even mildly critical of Signal, to the point where they simply suggest it shouldn't be the default recommendation, a lot of aggressive and weirdly emotional responses appear, along with downvotes.
Actually, I got emotional over nicoco's attack on Soatok. I don't really care about Signal.
I'll note that the parent's opening words were "The fuck are you talking about?" which clearly meets the "unkind" flag criterion, yet somehow they've got more votes than you. That's not an accident.
I was about to tag nicoco's original post as "unkind" before I decided to reply instead, because I consider their opening statement to be a rather unkind statement on Soatok. My "The fuck..." was my genuine first reaction to what I feel is really poor behavior.
There's a pattern here that's hard to ignore: people get extraordinarily defensive about Signal in a way that doesn't happen with other technical tools (even rust zealots wouldn't go in so hard). Whether it's coordinated or just emergent behaviour from true believers, the effect is the same.. alternative messengers get downplayed, criticisms get dismissed with hostility rather than technical arguments, and site rules get violated with impunity when defending Signal.
I barely even use Signal... Most of my comms are on Discord and Facebook Messenger, and most of my E2EE comms are on WhatsApp. I got defensive over a dishonest attack on a fellow techie. And, I don't think I even defended Signal?
If Signal's technical merits are so overwhelming, why does defending it require so much hostility?
Let's be real, people rarely make their decisions on any real merits, especially when it comes to stuff like privacy that most people haven't studied. I know one person IRL who uses Telegram a lot, but thinks Signal is probably compromised because, uh, the CEO hasn't whined about pressure from the government to give them a backdoor. Pavel Durov has said that he has received such pressure, so clearly Telegram is trustworthy and the right choice for E2EE! Technical merits simple don't factor in.
I got emotional over nicoco's attack on Soatok
Apologies for that, my post was absolutely not meant as a general attack on Soatok as a person. I see that 3 lobsters flagged it as troll, so I guess you are not the only one to interpret it that way? I'll edit the post to sound less aimed at an individual, let me know if you feel it is still "unkind".
EDIT: I updated my post to sound less "unkind" to Soatok, let me know if you think it's OK as it is now? Other have flagged it as troll, so I guess my tone was not right. I just dislike Signal is all, and I can be emotional about it too. :)
I read a lot more vociferous attacks on Signal here and on other tech spaces than I read defenses. Hating on Signal is a bit of a nerd shibboleth.
It's a decent article, but there are email clients like deltachat or k9 that deal with these things fairly well. E2E is there to bootstrap user trust for otherwise untrusted platforms because without it there is just TLS.
Email's problem is not encryption, it's usability. Lack of decent clients.
But, in any case, no matter how secure or safe a computer system is, my friends are not going to use it. They use Discord.
same goes for XMPP a bit, Signal really only solves cryptography and chatting from a UX standpoint for most people rather than a technical one
Again, I'm repeating myself a year later, this author, Soatok, is really frustrating and disappointing.
They're obviously knowledgeable about privacy and cryptography, and I respect that.
However, the product they always recommend for privacy, Signal, is plain bad. It is tied to phone numbers, it only works with Android/iOS (to use the desktop app, you need to have a phone with Signal), and it depends on proprietary code. I mean the last part is just great for privacy oriented product... (/sarcasm) I know people will suggest forks/alternative clients like molly.im, but other issues still hold. And don't get me started on the cryptocurrency pump-and-dump I already mentionned last time.
I like emails. I read them whenever I want, they don't pop in the notification bar of my phone. I can access them with multiple clients depending on my mood, from aerc to thunderbird including K9, and I want privacy in my emails. I do believe that GPG is good enough. Yeah, it's not the cryptographic marvel that the Noise Protocol is, but I don't care about forward secrecy, I don't care about plausible deniability. I just want to be able to send access codes, signed download links and legal documents over emails without my email provider or my recipient's email provider being able to read them, and with decent overall privacy. GPG does a pretty good job at all of this.
This whole anti-PGP discourse reminds me the cliché anti-MD5 crowd. Let's say I download a file from my own server, and I want to check there was no transfer errors or disk writing errors, MD5 is fine for that use case, I could have even used crc32. (I know that, nowadays, blake2 is faster and better, but md5 is still fine) Unfortunately, some people see MD5 and their lizard brain go "oh my god!! it's a broken message authentication primitive!!! You're doing it wrong!! You should be using scrypt!!" Yeah, but I'm not using it for authentication, I'm just using it for plain checksumming, and it's a good use case.
It's all about use cases. GPG is fine.
Also, it's not like the people developing GPG are idiots. Sometimes, I feel that the anti-PGP crowd are implying that without saying it out loud. I know that Soatok didn't, but the people that follow them on mastodon is not far from saying it.
Unfortunately, some people see MD5 and their lizard brain go "oh my god!! it's a broken message authentication primitive!!! You're doing it wrong!! You should be using scrypt!!" Yeah, but I'm not using it for authentication, I'm just using it for plain checksumming, and it's a good use case
You have this backwards: MD5 is fine in an HMAC construction (but not other MACs), and is absolutely not fine for guaranteeing integrity in an untrusted setting. You should not be using MD5 (or crc32) to detect anything other than accidental modification.
You also wouldn’t use scrypt in a MAC, since there’s no reason to make a MAC memory-hard. HMAC-SHA256 would be fine (but again, HMAC constructions are special in that they’re secure even when the hash function is insecure, so long as it’s still a PRF).
You have this backwards: MD5 is fine in an HMAC construction (but not other MACs), and is absolutely not fine for guaranteeing integrity in an untrusted setting.
This is not the use case that I described. I wrote:
Let's say I download a file from my own server, and I want to check there was no transfer errors or disk writing errors, MD5 is fine for that use case
I specifically chose a use case where I trust the source. In this case, yes, SSH or TLS will take care of the transfer integrity. But if I want to make sure there was no bitflip when writing to disk, md5 or crc32 are perfectly fine error detection algorithms. Maybe I used the word "checksumming" too loosely, I'll admit that.
You also wouldn’t use scrypt […]
Yes, if you don't trust the source, you shouldn't use scrypt. I was purposefully mocking the crowd that learned last week that md5 is insecure for storing passwords, and that they should use scrypt, bcrypt, pbkdf2 or argon2 with a random seed, or whatever is the algorithm du jour.
Yes, if you want to check the authenticity of a file, a trusted party should provide you a signed output of b2sum or worst case sha256sum. GPG or signify are acceptable tools to sign these outputs.
For me emails are just postcards. Sometimes i sign email if i want the recipient to know that yes truly it was me, but otherwise, i do not ever expect email to be "secure."
Whats a bit odd that the blog post first says "emails are not like postcards"
If you think about emails as if they’re anything but the digital equivalent of a postcard–that is to say, they provide zero confidentiality–then someone lied to you
Then later says that they are
You have virtually no email privacy. They’re like postcards, not envelopes.
Maybe I am misunderstanding something. Edit: Yes i read it wrong, ignore the above bit.
But in general i have no energy to think about encryption anymore. I'll use it if its offered but.. Meh. Its always a damn mess.
Whats a bit odd that the blog post first says "emails are not like postcards"
If you think about emails as if they’re anything but the digital equivalent of a postcard–that is to say, they provide zero confidentiality–then someone lied to you
I think the original sentence is a bit confusing, but I understand it as "Emails are the digital equivalent of a postcard. If you think about them as anything else, then someone lied to you."
Oh. I can see I misread it now, thanks. I blame english not being my native language.
English is my native language, and it took me multiple attempts to understand that first sentence. It's an odd structure and it's adjacent to a double-negative, both of which make it very hard to parse.
I agree that the consensus of people who understand cryptographic protocols better than me is that email (over SMTP and its extensions) is unsalvageable. That said, I at least mildly disagree about the political/social problem. A protocol does not need to "eat the world" to be useful. A communication channel that only connects some people is still useful to them. And it can grow.
The cryptography community seems to focus really hard on instant messaging, but email-like communications (structured, subjects, store-and-forward, asynchronous) are really important, and I think it's pretty clear that the way forward is to disregard the oligopoly, implement something like SMIMP. Now seems like a really good time for it, too, given the push to move away from services hosted by US companies. It's too bad that SMIMP itself appears to be DOA.