This is a post about my thoughts regarding encrypted email providers like and and a bit in general.

@lionirdeadman I concur, and use Migadu too.

Regarding PGP, sharing keys is pretty seamless once you set it up. WKD makes sharing keys from your own site/email domain really easy, without relying on any keyserver; since my email is, PGP programs like GnuPG simply download my public key from When I open a signed/encrypted email for the first time in my mail client (Neomutt), GnuPG automatically fetches keys via WKD, DNS, DANE, and a list of keyservers so I hardly have to lift a finger.

It also helps to expose a public key with IndieWeb microformats2 for better discoverability.


Well, the problems with using WKD is 1) You need to host your own web server 2) It assumes people will know how to set it up and have done so 3) It still requires people to manage and handle the keys.

These barriers to entry make it too hard for me to recommend it to people. Heck, I can't even do it myself because I use GitHub Pages.

I don't know, that's without mentioning the relatively weak encryption of pgp when compared to more modern protocols.

@lionirdeadman I get your point. I still recommend people use PGP if they're able to; email is one of the only open, well-supported, and federated asynchronous communication protocols out there, and is essential to decentralized git workflows.


I like matrix, xmpp is okay but I no longer know anyone who uses it so I just stick to matrix as my go-to for secure messaging.

Btw, does anyone encrypt email in a email git workflow? That sounds like a nightmare.

@lionirdeadman No, there's generally no reason to encrypt anything in a public mailing list. Private projects with multiple contributors are another story.

I'm not a big fan of matrix; the spec is massive both servers are incredibly heavy. A chat daemon should be lightweight to run on a single-board computer, and shouldn't use up an entire VPS. Even ruma doesn't look particularly lightwewight. Matrix also has huge feature creep that makes it difficult to implement a client that renders all messages as intended; making an IRC client is quite easy in comparison.

It's a shame that we don't have a protocol that combines the simplicity of IRC with the privacy and security of OMEMO/Olm (OTR doesn't cut it).

BTW, does github not let you add a ".well-known" directory to your repo? I'm surprised that they block the use of WKD.


I don't use mailing lists but that makes sense, ig.

Heavyness is a Synapse server problem afaik, Dendrite is lightweight enough that they crammed it in browser for the Matrix P2P experiment. Conduit seemed good too.

IRC might be more simple but it's also unusable as a modern chat program imo. IRC's simplicity is its biggest downfall. It can't cut it for mobile and it's just generally a bad experience.

I thought WKD required web server config?

@lionirdeadman For WKD, just add the directories/files and you're GTG. PGP clients will automatically figure out the desired URL from a filepath and download the key.

It's just a web directory with a key; a "Web Key Directory" if you will :akko_wink:.

Some tutorials online suggest some server configs to add a header or mimetype, but doing so isn't really necessary with any decent PGP client I know of. I dropped the directory into /var/www/ without messing with any server configs and it just worked.


Well, that's cool, I suppose. I still can't care enough to do it though, I just know I'll just never do PGP with someone because well, I don't email people.

@Seirdy @lionirdeadman won't work with github pages...

There are in fact two versions of wkd, direct and advanced.

What you suggested is the direct option however what actually happens is that first a lookup at openpgpkeys.$domain is made, then only if that fails the direct lookup is used at $domain/

Now, github fucked up the certs for the openpgpkeys subdomain and hence the lookup is invalid.

There's a rather long thread on the gpg-users mailing list about it.
@reto @lionirdeadman Huh, TIL. I was never much of a fan of GH pages, Netlify, and other alternatives to just running a server; they take away the freedom to do things like this.

The only (very understandable) advantage I see for developers familiar with UNIX is that they're free. I've been thinking about switching from a VPS to a single-board computer like to virtually eliminate hosting costs; it should be able to handle heavy load since my site is 100% static, most pages are under 10kb, and only gets non-deterministic parts are added in CI.

@rysiek @Seirdy

While I think Sequoia and pEp are doing great work, I believe it is not easy enough for the average people to care.

Of course the security conscious can learn it and live through all the barriers but that means nothing when I spend most of my time receiving notifications through email or sending casual emails.

I believe that for people who do not care, the simplest solution while keeping in mind federation is Matrix.

@lionirdeadman @Seirdy not entirely sure about pEp:

But yeah, @sequoiapgp is doing amazing work.

The barriers are slowly coming down. Autocrypt, WKD, more workable OpenPGP implementations (like sq), better keyservers like Hagrid, all this leads to better usability in the long run.

The alternative currently usually boils down to one of the walled gardens, or Matrix, and neither is a good replacement for e-mail.

@lionirdeadman @rysiek Unfortunately, Matrix is primarily for IM: synchronous unstructured chat. For subject-delimitated async threaded discussion, the only federated platforms to gain traction have been Usenet and email.

If you browse through a mailing list's archive or usenet group, you'll see that it's more like a slow forum than a chatroom; this promotes a very different style of discussion.

@Seirdy @rysiek

AFAIK Matrix is flexible enough to do threaded discussions like email but none of the clients do it. The closest thing would be that Microblog-like experiment they showcased a few months ago.

Also, I totally get the difference in style of discussion. I just find it hard to believe that pgp would ever scale to enable these conversations.

@lionirdeadman @Seirdy there are encrypted mailing list managers like Schleuder. I have run one, it works pretty well.

There are PGP-encryption-smtp-proxies (for a want of better word) like koverto. That means all software that sends mail can now be SMTP-proxied through koverto to get signed/encrypted mail from tools like Nextcloud, Gitlab, whatever else.

There are tools like OpenPGP-CA that can allow organizations to use OpenPGP kinda like S/MIME is used, simplifying key management.

@lionirdeadman @Seirdy

And more importantly, OpenPGP is a well-understood protocol. We know what works and what doesn't. Frankly I have more trust in OpenPGP's security currently than I have in Matrix.

@lionirdeadman @Seirdy I have run infrastructure for a large (100+ people) org, where everyone had an OpenPGP key, PGP was broadly used for communication, automated e-mails from our systems were all signed and many encrypted (depending on a given service), group mail was PGP-encrypted, and verified keys were automagically pushed to WKD.

Our team was not dozens of techies, either. There was some friction, today there would be less.

Main reason people don't do it is because they were told it can't work.

@rysiek @lionirdeadman Err, OpenPGP's security is...dated, to put it mildly. Supports weak algos, no PFS, scope creep, and a long list of other issues. Age for encryption and Signify/minisign for verification is a much stronger generic approach. Almost every cryptographer and security researcher who's looked at PGP would say something similar.

Matrix uses Olm, which in turn uses double ratchet encryption (a component of the Signal Protocol); this is miles better than what OpenPGP provides.

Email is an inherently insecure protocol but it's the best we've got until someone finds a way to translate Matrix threads into nested treelike subject-delimited threads resembling a maildir.

All of this assumes that message metadata like senders/recipients/timestamps isn't sensitive. No open and federated protocol I know of can hide this data *and* authenticate users; the best we have is the full Signal protocol with Sealed Sender, which is inherently non-federated.

I'm not entirely sure whether you're saying that sealed sender could not be implemented in federated protocols... Are you? If so, could you explain why?
@lionirdeadman @rysiek

@Seirdy @lionirdeadman give me a federated protocol with newer crypto that has a fighting chance of replacing e-mail in all it's multitude of use-cases (direct communication, mailing lists, automated messaging, sending attachments, trivially adding/removing people from threads, CC/BCC, forwarding messages) for regular people, and I shall sing its praise.

I am not aware of any such thing at this point, though.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.