Galaxy photo

The Fediverse should avoid bundling Private Messages completely and implement this instead.

Many servers in the Fediverse have implemented “private mentions” or “private messages” or “direct messages” in a manner that uses the ActivityPub protocol without encryption. Fediverse server administrators are able to read all of these private messages on the server which means they’re not really private.  Some have suggested making them encrypted so that server admins can’t read them, but that poses more problems. For example, who’s responsible for enforcing local laws on the server?  Will server admins be liable for content privately created by users of their server?  Do server admins really want to deal with those potentially major legal issues?  Not likely!

“Public” and “private” should be completely separate

I consider public social networks like the Fediverse analogous to large public conferences or meetups or festivals or even a bar. There will be lots of strangers there and it’s fun to talk to them out there in the public. But do I want everyone there to be able to call me on the telephone at home whenever they feel like it just because I existed in a public space? Absolutely not!  I’ll decide who I may want to communicate with further privately and give them my business card with my email address on it. If I don’t specifically give them access to my private communications method, they shouldn’t be allowed to contact me outside of the public space. 

Offload private messaging

Keeping private messaging away from the public messaging of the Fediverse makes a lot of sense and provides many advantages. Just like there are advantages to having a different DNS server, web server, database server, and email server… you don’t want to put all of your eggs in one publicly accessible basket. You probably don’t want to buy a couch for your private home from the same company that makes public roads either, right? 

The whole reason other social networks bundle private messaging with public messaging is to take control of their audience and leverage all of your conversations to profit off of you.

By de-bundling the private messaging from the public messaging, you can:

  1. Choose a different private messaging server with different features than what may be bundled with your preferred Fediverse server.
  2. Switch public messaging Fediverse servers without switching private messaging servers.
  3. Implement any kind of encryption you want on your private messaging server without changing your public Fediverse server.
  4. Use your existing preferred private messaging client app without having to spend cognitive energy on learning something different.
  5. Use your existing preferred private messaging workflow.
  6. Use all of the existing robust messaging management tools for spam control and moderation.

By de-bundling private messages from public messages we can have a system that specializes in public messaging and a separate system that specializes in private messages. 

Email is probably the best choice since it’s already built-in

Most Fediverse servers already have a method to send private messages to everyone using a different external server. Just about all of them require an email address to sign up and then that email address is verified as being functional by sending an email to that address and requiring the activation of a link in order to activate the Fediverse account. The email is also used to reset passwords as well as send notifications of things like mentions, follow requests, and even… get this… private messages! 

Well, look at that! We already have a better method of sending private messages!  The problem is that these notification messages can’t be replied to because the server doesn’t accept incoming emails.  But again, we don’t want the public server to handle private message exchanges, remember?  

The simplest fix would be to have the sender’s Fediverse server include the sender’s verified email address in the private message request, then have the recipient’s server populate the email notification’s “reply to” field with the sender’s email address.  Then recipients can reply to senders using their existing email account, existing email client, and existing email encryption methods.

In fact, both people have a huge amount of flexibility now since the email ecosystem of clients, servers, spam blockers, workflow integration, encryption options, and management tools is vastly more robust and superior to any other messaging system in existence.

Another implementation idea that I like is to simply have a “Contact” button on each profile that shows a “message” field along with a “send” button and a little indicator that says “your message will be sent to the profile user’s registered email address”.  Pressing send, sends the message to the recipient’s email account using the Fediverse server’s existing configured SMTP server and includes the sender’s registered email account for replies. 

We’ve already been here before.

With email, we’ve already learned all of the lessons about private messaging. It used to be that people would post their private email address all over the internet, handing it out to anyone who asked. This caused people to huge floods of spam messages all the time. We quickly learned to compartmentalize private messaging by giving out dedicated spam addresses to those un-trustworthy people, and keeping actual clean private accounts for the people we really want to privately communicate with. Furthermore, we’ve got dozens of other software programs and systems for mitigating and managing private messaging emails as well! I’ve got a contact form on my public website that already filters out robots and then sends me the email address that the sender wants to be contacted on. I can then decide which account I want to reply to them on based on how trustworthy they are and what type of conversation we’re initiating (business, sales, spam, etc.). 

In fact, the very first internet social network; usenet, actually used email for private messages. Each usenet post had an email address associated with it and you could just email the person if you wanted to send a private message. So simple!  Of course, that didn’t have any way to really block bots from scraping all the email accounts, but still in a high-trust scenario, it makes a lot of sense. The Usenet culture was very much tilted towards keeping public messaging public though so taking conversations private via email was often frowned upon as it should be with the Fediverse. Also see: Federation and moderation: Usenet as the original decentralized social network — GNU MediaGoblin (

Bundling can still be an option

Of course bundling private messaging with public messaging should also still be a choice that server admins can have. Just like you can choose to run a website on the same server as your email, this should be possible with Fediverse servers… and it is!  Librem One by Purism already disables direct messages on their fork of Mastodon and integrates their own hosted email service as part of the bundle. There shouldn’t be anything stopping anyone from plugging a webmail email system into the private messaging interface of a Fediverse server. Sticking with email though maintains the advantages of global interoperability with the 4.2 billion user base along with all of the other management tools that already exist for email. 

Advantages of email based private messages

Let me put it all into a nice list form so that it’s easier to scan and process.

  1. Every Fediverse user already has an account verified during the sign up process. We know it will work because it was tested during sign up!
  2. Every Fediverse user is already familiar with how to use email since it’s a requirement to make an account. It’s also (practically) a requirement to use any consumer electronic device that connects to the internet (Android, iOS, MacOS, Windows).  This increases cognitive ease and convenience since you already have to know how to use it and have an email based messaging account.
  3. The ability to send emails is already built into most Fediverse servers. Currently they are mainly only used for notifications and password resets, but could easily be modified to initiate email-based conversations if only the sender’s email address was included in some way such as the notification’s “reply to” field.
  4. Individuals can choose separate email servers for private messaging versus separate Fediverse servers for public messaging without having to find one that handles both satisfactorily.
  5. Individuals can use the email clients they’re already familiar with and have probably been using for decades. Or they can choose a different one and compartmentalize or organize messaging however they choose.  If you want a chat style interface, you can use Delta Chat, Spike, Email Messenger, etc. If you want a command line interface you can use mutt, neomutt, or emacs. If you want to use a web-based interface, there are plenty of webmail options as well. You can even switch between them whenever you feel like it with no need to add code to a Fediverse server. 
  6. Existing email clients and servers have a huge ecosystem of moderation and privacy capabilities. There are plenty of alias services, multiple account capabilities, and anonymous address options that don’t exist for the ActivityPub protocol.
  7. Existing email systems have a huge ecosystem of encryption options (TLS, DANE, Criptext, Autocrypt, PGP, MIME, Tutanota, Protonmail, etc.)
  8. We can add read receipts or click tracking or block those in email. The choice is open to everyone. 
  9. Email has many integration options with scheduling systems, task management systems, video/audio conferencing systems, billing systems, etc. 
  10. Email systems have many robust auto-reply, categorization, filtering, and sorting systems.


Email is insecure

That was certainly true 30 years ago, but just like the web, email has evolved since then. Most servers use TLS transport encryption now with client transport encryption. Content encryption is easier than ever with the Autocrypt standard. Of course there are numerous other methods of encryption and security that you can choose to implement as well. 

Besides, it’s secure enough to use for existing password reset links, notifications, and user verification. If you need more security than that for private conversations, then you should definitely offload your conversations away from the public Fediverse servers. 

An integrated messaging platform is more convenient.

Having to manage yet another “type message press send” app to manage is the opposite of convenience. Convenient would be having one place to manage, organize, and respond to all of my internet communications. Segregating them based on server type causes much more work and an increase in cognitive load.

Private messaging from the same public messaging app is easier

Yes, hitting one button an @ symbol followed by typing someone’s name is pretty easy, but I would argue that this is too easy.  Simply knowing someone’s public fediverse handle means spammers can flood everyone with private messages. We’ve already learned this lesson with email in the 1990’s, remember?  You’ll have to rebuild all of the anti-spam and moderation tools that we already have in email in order to avoid the same issues email had 20 years ago.

Starting private group messaging conversations is easier

If you want to start a multi-person private conversation with people you know in the Fediverse, it’s easier to simply type all of their names into a new message especially if you don’t already know their email addresses, but again this is a potentially unwanted scenario. I don’t want everyone I follow on the Fediverse to have permission to add me to any messaging group they want to. This has happened on other platforms before and it’s usually awful. Simply creating an anonymous account on Telegram gets me added to dozens of cryptoscam private messaging groups. Similar things often happen on Facebook messenger and Whatsapp. It’s a very annoying spammer and scammer technique and individual user permissions probably shouldn’t default to allowing that. 


“Type message, press send” doesn’t need to be as complicated as society has made it these days! We have a completely open federated standard protocol that happens to be used by the entire population of the internet for everything from activating phones to subscribing to streaming video services to buying/delivering products to paying taxes to renewing car registrations. All of which can be done in a privacy friendly and secure way. 

Isn’t it smarter to stand on the shoulders of giants than trying to rebuild what we already have? 

Related Discussions

Photo source


  1. I do not even understand how I ended up here, however I thought this put up was good.

    I don’t realize who you are but certainly you are going to a well-known blogger in the event you aren’t already.

  2. whoah this blog is wonderful i like reading
    your posts. Stay up the great work! You understand, a lot of people are hunting round
    for this information, you could help them greatly.

  3. Hello there, I discovered your web site by means of Google while searching for
    a similar matter, your site got here up, it looks great.
    I have bookmarked it in my google bookmarks.

    Hello there, simply became aware of your weblog thru Google, and found that it
    is really informative. I am going to be careful for brussels.

    I’ll be grateful for those who proceed this in future. Lots of
    other people will likely be benefited from your writing.

  4. Hello very nice blog!! Guy .. Beautiful .. Wonderful ..
    I’ll bookmark your web site and take the feeds additionally?
    I am glad to seek out numerous helpful information here in the put
    up, we want develop more techniques in this
    regard, thanks for sharing. . . . . .

  5. After checking out a number of the blog articles on your
    website, I honestly appreciate your technique of blogging.
    I book marked it to my bookmark website list and will be checking
    back soon. Please check out my web site as well and let me know your

Leave a Reply

Your email address will not be published. Required fields are marked *