Email is already nicely federated, but I think it’s time for a change. Services like protonmail offer encryption between users, but you can’t host your own instance. It would be awesome if there was a spec somewhere for a federated email service that defines

  • email encryption between users
  • markdown
  • connection with activity pub? (What would this look like) I mean some way to “email the web”, ie: add comments via email
  • compatibility with standard email users (if you send/receive to/from a user who does not have email v2 implemented it just uses normal features)
  • maybe “smart attachments” for money transfers, calender invites, etc.
  • somehow better support for email discussion groups
  • this spec should be focused heavily on usage for humans instead of automated mailing, I expect html would not be defined.

I’m just spit balling here. Does anyone have any ideas? Does something like this exist?

Thanks, Evan


From this hackernews post:

Unpopular but very probably true fact: email can’t practicably be made secure, and people should stop trying. Email is itself archaic, and there aren’t good reasons people should use it for routine peer-to-peer communications that need secrecy.

Why? Because:

  • It’s default-plaintext. We don’t generally love the way websites ensure they’re viewed securely, but email doesn’t even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.

  • Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you’ve ever sent in the past is too. That’s a terrible property for a secure messaging system.

  • Email leaks metadata. In fact, some of what we call email “metadata” isn’t even metadata — stuff like subject lines are simply content. They’re sent in plaintext. We would never accept a new secure messaging system that behaved like that.

  • Most email users get their email from a website. Unless you make them install something on all their computers — and at that point, just get them to install Signal, WhatsApp, or Wire — “encrypting” their email involves schemes in which those websites can get their plaintext mail.

  • Most email clients are searchable-archive-by-default. Again, if you’re using a secure messaging system to keep secrets from a state-level adversary, that’s exactly what you don’t want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?

Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.

deleted by creator

Technically speaking this is Matrix, if you create a GUI that looks like an e-mail client instead of an instant messenger.


That would be indeed a better use for the Matrix protocol then as a messenger.

For the first you already have Autocrypt implemented in several clients including Thunderbird and Delta Chat.


I honestly believe email is beyond salvage… even GnuPG is now compromised by funding through and cooperation with German intelligence services.


email encryption between users

Already exists, but it’s not offered on most WebUIs


Would be a nice idea, but in my eyes more a client side feature

connection with activity pub? (What would this look like)

Please not. As far as I understood, activity pub is used for public messages, which emails are never meant for.

compatibility with standard email users, the features are simply not activated

What is a “standard” email user?

maybe “smart attachments” for money transfers, calender invites, etc.

Calender invites are working with ICS files, if the client uses the file correctly. Also Groupware like OX, Kopano (Zarafa), … already uses this feature since first release.

somehow better support for email discussion groups

Better support for mailing lists? How do you mean this?

this spec should be focused heavily on usage for humans instead of automated mailing, I expect html would not be defined.

Emails only transport what you give them. Clients translate HTML content, but you could also send just markdown in text format.

Most features I see listed are client side features. One could contribute to open source email clients like Thunderbird, Evolution, KMail, Geary, Sylpheed, Claws Mail or Mutt and suggest such options. You could also look at DeltaChat, which already implements a few of these features and can also handle “normal” emails. Some even use it as their only email client.
Mail clients like Spike, for example, already go other ways and display emails like a conversation, like DeltaChat.

Unfortunately, however, most use email via a WebUI or Outlook. Add to that, many uses Gmail, even many wannabe Mastodon instance provider. And we all know how much they love to receive ideas from others.

A federated email delivery system with the emails my own server would be good.

A community dedicated to fediverse news and discussion.

Fediverse is a portmanteau of “federation” and “universe”. It is a common, informal name for a federation of social network servers whose main purpose is microblogging, the sharing of short, public messages.

Getting started on Fediverse;

For devs;

  • 0 users online
  • 1 user / day
  • 5 users / week
  • 39 users / month
  • 224 users / 6 months
  • 3 subscribers
  • 250 Posts
  • Modlog