Discussion
@scottjenson And on encryption, I think you could probably launch with UX improvements only, and leave encryption as a "fast follow". E2EE might not be *critical* but it's a *super-nice-to-have* ~ especially on today's internet.
The fact that we call them "direct messages" isn't enough; people have a natural expectation of privacy when they send DMs, and the Fediverse doesn't really honor that right now.
The more systems we can make "secure by default" the better.
@scottjenson
> How critical is it that these message are encrypted?
If you're going to do DMs at all, it ought to be in the roadmap from day one. A SocialCG taskforce is actively working on E2EE DMs for ActivityPub, using MLS (cc @evan), so you don't need to do it alone.
> If we were to make some UX changes as a first pass WITHOUT encryption
There's never a bad time to improve UX. Making it harder to confuse public and nonpublic posts, for reading and especially for sending, would be great.
@scottjenson@social.coop Private mentions aren't really private if they're not end-to-end encrypted. On a federated platform, you put a lot of trust on the servers, and it's not just the one you're on but also the one receiving the messages. What if I want to message a friend on Threads for instance? I don't know about you, but I don't trust Meta to just deliver the messages without using them to build a profile on me or improve their AI models, which are things I can't really opt out of since it's not my platform. The only way to avoid these things (to some extent) is to make it impossible for them to read my messages.
The good thing is you don't have to reinvent the wheel here, there are already a few attempts at standardizing encryted messages for ActivityPub: Evan put together the MLS over AP, Hollos also did something similar. Make sure to talk to them so we don't end up with yet another standard.
@Varpie I did just check out Hollo (Hollos?) and it appears to be a server for just 1 account so it's not clear HOW it's handling this. (I'm not going to install it for just kicking the tires)
For me, the biggest issue is setting up/managing the keys. I'm hoping to find any implementation that shows how to do this?
It's not enough to show a technology demo, we have to have something mere mortals can turn on without a multiple step configuration process.
@scottjenson@social.coop True, handling the messages in a standardized way is one thing, but managing keys across multiple clients is the hard part here. The way I see it, there are 2 options:
The first option allows to handle each client separately, so we don't need the other device to be available and if we want to stop using a specific app, we can deregister it, but it requires senders to encrypt their messages n times, and as mentioned it makes it difficult to handle chat history.
The second option makes chat history trivial, but it puts a lot of trust on new clients, if we want to stop using it the rotation of keys is more complex. Also, each client needs to be able to handle the same type of keys, which isn't a given when using different apps.
I think for user experience, having each client generate its own key and asking older clients to re-encrypt messages with the new key can be better: there is no requirement to have the other clients active at the same time, but we can have the same handshake that would be required for passing PKs, to recover chat history. It also allows to give more granular control over which clients are active, kind of like seeing the active sessions for an account and being able to log off on other devices.
@Varpie I just found https://holos.social/e2ee which explains how keys are generated per message and using the actor in activit Pub allows the sender to know if the recipient is capable of receiving an encrypted message. It seems pretty slick and looks like it's almost ux-free with a few unanswered questions.
@scottjenson@social.coop This is great but it assumes a single device (private key) per account. What if I want to have a phone and a desktop? Whatsapp and Signal both "solve" this by having one main device (the phone) and connected devices that make use of this main device's private key, but in the context of having different applications connected to a fedi account, I'm not sure it would work too well.
@Varpie exactly. This is why I'm treating this topic as something potentially quite difficult. One of the incredible values of the fediverse is that I use multiple clients to manage my account and I'm worried that encryption will make that nearly impossible.
imo social media and social networking are different things. mastodon is the former and doesn't need privacy. it's public and about going viral. encryption is needed for the latter. direct messaging and groups. #ActivityPub vs #matrix.
I use Mastodon DMs.
I want encryption, but there is something higher priority for me —
Being able to see ALL the DMs for a single user (that I have talked to) in a single place. Rather than having them scattered all over the place.
I get that these scattered DMs are the result of separate conversational threads, but — I would still like to see them all (from a single user) in one place.
I'm probably just one more vote on a "me too" pile, but it's not critical to me that social timeline 1:1 messaging be *encrypted*. It's important that I (the generic user) *understand* whether it is or isn't and behave accordingly.
If you have to pick a focus, I do strongly prefer that 1:1 or 1:few comms have a distinct workflow apart from regular/public timeline appearances, though. It makes mishaps less likely, like forgetting or mis-clicking "private" in that dropdown.
@scottjenson count me in "use secure messengers for private communication". I know people will keep trying to use social media for it no matter what, but in my mind it's a misuse, and shouldn't be a priority for fixing. (I didn't do any research, just speaking from vibes!)
@scottjenson
Signal is my go-to when I feel there's a need for #Encryption. If it was available in Mastodon for private messages, I'd probably use it.
I don't think the Fediverse is on the radar of the current administration here in the US yet, but they might be someday. What happens when law enforcement types show up at a Masto admin's doorstep? Do they give up all the data willingly? Even without a subpoena or judge's order?
@scottjenson Encription should be an option, not a must.
Not everything should be hidden, and by reducing the cpu time you'll reduce the carbon footprint, too.
(I'm talking about end-to-end encryption here, not about user's AAA or inter-server comms).
Personally, I hate this modern trend of hosting public blogs via HTTPS. Not everything should be encrypted!
@scottjenson I'm not against interface improvements, or even doing that first, but I'm all in on encryption.
Mastodon is all about privacy and putting users first. When I DM someone the whole point is that the message is only for them. I prefer that administrators not be able to see.
@scottjenson Hi Scott, I believe the option is complex, honestly.
Encryption is tricky but I also think it provides layers on top of the communication that might make it feel larger than a quick "dm"? I can't speak to others obviously but Mastodon should consider what solutions you are providing and if they make sense for the platform.
Encryption is useful, but does it make sense for Mastodon? Is that the direction the social media tool is moving? Encryption-focused 1:1 communication?
@jackryder all fair questions! All I can say is that there are many within the community that are quite adamant that DMs must be encrypted. The most common reason is that they don't want admins to spy on their posts.
My concern is just that setting up E2EE is rarely a simple process. I expect it to be a ux challenge to make it easy.
@scottjenson I appreciate the response and transparency.
I believe I understand the fear for concern and secrecy. I don't believe there will be a simple & straight forward solution. As you said, "just setting up..." is often a lot trickier than we anticipate.
I'm not familiar enough with the stack to know what would need to change. I imagine there are quite a few underlying systems that would need at least partial rework and that alone would cause for a trickle down effect on literally everything. Ouch. I wouldn't envy sitting in on those prioritization calls.
Personally, though I don't mean to sound diminishing to the population I would do exactly what it looks like you guys are doing. Checking the temperature and prioritizing the needs. Kind of glad to see people actually asking.
@scottjenson For it's the expectation of privacy for private messages that makes encryption a requirement, not an option. Depending on the jurisdiction of the instance, authorities might be trivially able to get all content, including private messages. Also, instance admins might snoop around for whatever reason they think is valid. Encryption by default is the only way to guarantee privacy expectations. 1/2
@scottjenson I think that every message not meant as a public broadcast should be end-to-end encrypted, regardless of the app or service that people use to send it. People shouldn’t have to worry if the information they’re exchanging is private and secure or not. It should be table-stakes these days, just like HTTPS is for websites. When you create a website, you don’t ask yourself if it’s sensitive enough to need it, it’s just common practice to generate an HTTPS certificate for everything.
@scottjenson I believe that as long as we are transparent about encryption status, it's not a problem.
@scottjenson I think all of these ideas are addressing the fundamental disconnect that DMs are a fundamentally different "thing" than posts. I worry that a dedicated interface, separate notifications, etc. strengthen that disconnect.
So then when those posts aren't encrypted, or you tag someone and they get a notification about it, you're even more surprised.
Encryption itself isn't a critical feature, but helping new users grasp that private mentions are not DMs is a very difficult Ux problem
@scottjenson Any UX improvement would be great.
Maybe it is possible to integrate something like XMPP or MLS later for encrypted DMs? They could both federate too.
@scottjenson@social.coop
There’s a deadly footgun embedded in Mastodon’s “private mentions”—any account that is @ mentioned receives the message, even when they are not the intended recipient. For an example of how this plays out, check out the “Direct messaging does not work” section in this April 2025 blog post.
Referring to someone using @ mentions is part of the muscle memory of Mastodon users. (Convenience plays a major part, @ mentions provide autocomplete options once you type in a few characters.)
In the past, Eugen Rochko had defended this as behaviour that a user should expect. In other words, he considers this behaviour a sane default. Maybe. (A completely different UI paradigm only for “private mentions” will be tricky, it will go against user expectations—I understand that.)
But in that case, I think enabling end-to-end encryption for “private mentions” is kinda pointless.
@dialecticalmusings Thank you. This has been mentioned by others as well. I can see how this behavior could be problematic.
@scottjenson
I'm not here for encrypted messaging.
@scottjenson I think encryptef messages are important, but I also think that lower-hanging fruit (e.g. improved UX) should be done first
@scottjenson encryption is not trivial. Focus on the basics and get them nice and convenient. Then try to solve the encryption puzzle :)
@scottjenson Please make UX improvements first. Adding complex encryption won't make a difference when people accidentally send a public toot thinking it's private.
@scottjenson
Seems like another way to ask what you're getting at is "would you consider improvements to private mentions useless without encryption?"
My answer to that would be no. There are plenty of other options for encrypted messaging.
@scottjenson without encryption, what is the point of calling it a "private mention" ?
@scottjenson I would love to see UX improvements. Make it clear the limitations of "Private" Mentions. Make it hard to send a PM publicly. Users are misusing PMs now. The UX doesn't help the user. It would be nice to help them as soon as possible.
E2E would be fantastic, but encryption is going to take a while. And like another reply wrote: I'm not convinced it is possible on a federated system given email and xmpp still have only bad solutions to encrypted messaging.
I think some people were using PMs for potentially sensitive info (addresses, Venmo, etc.), and having them slightly more secure puts people at ease.
What about standard public-key stuff, dropping a short public key in a metadata field, keeping the private key on the endpoint or in the client?
@knapjack
How can the sender validate the public key hasn't been tampered with by the instance or server admin?
It is a hard problem. There are solutions but it will be complicated.
For sure. Mainly I'm thinking about "Pretty Good Obfuscation" than a good solution. Something better than in the clear.
Really, delivery isn't guaranteed, so there are already potential issues about tampering that encryption won't necessarily fix, just maybe make abusing it harder.
@knapjack I understand where you are coming from. I might have agreed a few years ago. But encrypted messages need to be rock solid. Recently many governments the world over have shown they are more than willing to use the courts to subvert encrypted communications. Including forcing service providers like your friendly Masto admin to both hand over data and backdoor encryption.
I hear you.
I guess for me, I'm not going to use social media for that kind of thing, but I've exchanged snail mail addresses with online acquaintances and not sure if I would ever do that via the Fediverse with the current implementations.
I can also see that in my head, my implementation would never have the private key server-side on a shared server, which would make it useless via the web. Honk and snac have spoiled me. But I could see having a private key in one of the mobile clients and never on a server.
@scottjenson not at all critical.
Hint: you could re-run this as a poll, for the question.
@grahamperrin Oh I plan to! But it helps to have a conversation first so I know WHAT to put into the poll...
@scottjenson I rarely use them due to the UX fears, encryption would be a cherry on top
@scottjenson And on encryption, I think you could probably launch with UX improvements only, and leave encryption as a "fast follow". E2EE might not be *critical* but it's a *super-nice-to-have* ~ especially on today's internet.
The fact that we call them "direct messages" isn't enough; people have a natural expectation of privacy when they send DMs, and the Fediverse doesn't really honor that right now.
The more systems we can make "secure by default" the better.
And.. you probably know, but just in case:
We have a solid spec for E2EE on the Fediverse now (https://swicg.github.io/activitypub-e2ee/mls) with #Emissary and #Bonfire launching later this year.
As you'd expect with end-to-end-encryption, *most* of the work is on the browser/client. The AP server changes are minimal: a new KeyPackage object to store, a new collection, & other small stuff.
When we have working JS code, it'll be AGPL, and you could use it as a baseline for Mastodon 😎
@scottjenson And on encryption, I think you could probably launch with UX improvements only, and leave encryption as a "fast follow". E2EE might not be *critical* but it's a *super-nice-to-have* ~ especially on today's internet.
The fact that we call them "direct messages" isn't enough; people have a natural expectation of privacy when they send DMs, and the Fediverse doesn't really honor that right now.
The more systems we can make "secure by default" the better.
@scottjenson Hey Scott! I'm so glad you're tackling this issue. I have lots of trouble with DMs on Mastodon. I think you're addressing, these, but here goes:
The biggest one is how easily they're confused with regular messages. I routinely mess this up, and make private messages public, or vice versa.
The next is how hard it is to visualize threads - especially in the existing notification section. I often lose my place in complex discussions
@benpate Could not agree with you more! Do you have any ideas on how to improve threads? Any products that do it well for example? Branching threads are a bit like merging PRs, the dependency tree can get crazy complex!
@scottjenson @benpate is there a reason private messages need to support threading? Most DMs on other platforms are flattened to a single thread for simplicity.
If threading is still necessary, iOS’s design for replies to specific messages in iMessage feels easy to follow for me
Hey Jesse ~ great point. It would probably depend on how people use it. And private/direct messages are probably different from comment threads on public posts.
For public messages (like this one) it feels like people have the expectation of real threads.
For private messages, I agree with you & have been considering iMessage's method: showing everything chronologically, with 1) a note if something is a direct reply and 2) the ability to "zoom" in on replies.
Yeah, it’s a sticky problem, and better designers than I have struggled with it. I did a tour of different solutions, but didn’t come away with any slam dunk answers.
It probably depends on the use cases you anticipate most. 😟
I settled on something close to Reddit, showing nested replies + a “focus” widget that follows a single thread “up” to the original post.
I can share some screenshots/drawings if you think it would help to visualize.
@scottjenson I think making UX improvements to DMs is a great idea.
One of the biggest privacy problems with Mastodon DMs now is that people accidentally make them public.
Separating the private mention UI from the public posting UI will probably avoid a huge percentage of those user errors.
It'd be a big win for privacy.
@evan @scottjenson
phanpy does a great job
@virtuous_sloth @scottjenson actually, it doesn't separate the composition of private mentions from other types of posts. It's an option on the drop down. If you forget to change the option, your PM goes out with the default visibility -- often public!
@evan @scottjenson
But if you forget to set it to PM, there are no stripes, which should be a jarring visual clue.
I suppose adding a second compose button would make you choose sooner, but ultimately you have to always click on the right buttons in the right order.
They could change the default when you are viewing your PM list. That would make sense.
This is what I meant that there are lots of things to look at here. As Evan points out, let's make PMs actually something distinct and clearly not a message. Too many people either think something is a PM and it isn't or it is, and it shows up in your feed which makes people panic!
So many simple things to clean up here.
@evan the already improved UX looks good, to me.
When drafting a reply to a public toot, the word 'Public' is prominent (first screenshot).
When drafting a mention, the separation is clear (second shot).
Without being blasé about privacy: if a person accidentally publishes in either of those contexts, it's human error.
@scottjenson encryption that still works if one of the parties changes fediverse servers seems like it maybe technically challenging
I also would note that a lot of my interactions on the Fediverse are not very “microblogging” focused. Ie this response isn’t a blog post.
I largely use DMs here for private but non sensitive content (like “hey your url is broken” or “you have a typo on that post”
@Rycaut Exactly. My hypothese is that most PMs are scoping outisde of the public discourse and are not in need to encryption. This doesn't mean it's not a good long term goal! Just saying lots of usage does not require it
@scottjenson Thanks for asking! I'm a big fan of Encrypting All The Things, but my impression here is that the dangers of PMs on Mastodon have more to do with the potentially confusing UX, so I think addressing the UX issues would help the most in the short term.
Ultimately, I want users to be able to assume "private" means encrypted, so I'm very glad that's part of the plan. Yes, people can use Signal, but there's still a need to privately transmit one's Signal username at a minimum. Also, private threads can stem from public threads, so it's natural to have some facility for privacy here. Finally, I'm a huge Signal fan, but its centralization means a single point of failure, and makes it a huge target for authoritarian state actors, and I worry about it going down or being compromised.
I would like to see more visual distinction between public and private posts, like different coloring, so fewer people confuse them.
@scottjenson I must request encryption, because even though I don't need it right now. ...
A - you never know when you might need it
B- if I did, I might feel really uncomfortable telling you the reason, so I'm gonna assume that I'm piping up for some of those folks.
@morst No one is saying encryption is off the table. Just that I wanted to start with low hanging fruit (bucause the improvements are so much easier. Others are working on the encryption (it's a VERY hard problem)
@scottjenson My take is encryption is important, but not important enough that you shouldn't make UX improvements before having it
I particularly would like to see the list of mentions decoupled from the list of recipients, though I wonder if that might cause problems with replies from some software... but still
@jfred You're not the only person asking for this. It's a resonable suggestion (but I can't comment on the implementation complexity)
@scottjenson I know @soatok is working on E2E DMs for the fediverse.
But I already kinda use the existing DM feature but it is very clunky depending on the client you use. Having some sort of prominent tab that has it's own set of notification so I don't miss it in the flood of "normal" notifications would already go a long way.
@scottjenson I think any service with an implication of privacy should be encrypted, but that encryption needs to be done right. And the UI needs to convey the level of encryption clearly so people don't make incorrect assumptions about the security of their communications.
So I'm okay with the UX coming first, if it's designed with future encrypted messaging in mind.
I get DMs are not the focus of the app, so probably not a big priority, but they are still useful and important to many users.
@aaron Completely agree and why I'm asking. We can do both: improve the backend (adding encrypting) AND improve the UX. This is especially true as the frontend improvements are far easier to implement so people can benefit from this WHILE working on the backend.
Signal makes it easy to create a revocable "message me" link. I have one in my profile. If anyone wants to send me an encrypted message they can click on it and send one pretty easily.
I think reply controls and UX improvements should come first, maybe with, as others suggested, a note that the message is not encrypted (yet)
@gbargoud makes sense, thank you
As an aside, I'm surprised there isn't an instance at a link like staff.joinmastodon.org with an official account for each member of the core mastodon team.
I had to check your profile to see that you were someone asking for feedback who could do something about it rather than someone who was asking out of curiosity
@scottjenson imo that’s totally fine. Just need to make it known straight up that the messages are not encrypted, which is more or less just an alert that hard blocks interaction until acknowledgement…
@scottjenson I am kind of surprised that no one has mentioned that "oh the admins of the servers shouldnt see my DMs!" Creates a moderation nightmare and a harassment loophole that really shouldnt be considered worth the hassle. I am on team "just use signal" because if you need to have a really private conversation with someone who didnt give you their private contact information, no you dont.
@Montaagge There is a lot of traffic on this thread and that point has been made by the way. It's a reasonable request. I just appreciate that it's not a simple ask and I'm hoping we can tackle some UX improvements WHILE the background work is going on.
@scottjenson one huge problem with private mentions is that they actually aren't equivalent to DMs... because if you try to talk about another person and link to their profile, you effectively "mention" them and they can see the message. I don't know of any other DM that works this way and the UX is extremely confusing to users and just wrong IMO.
I think private mentions should be scrapped entirely and reworked as a different AP object type than Note so that they are treated differently.
@scottjenson Adding a vote for encryption first. For the simple reason that “personal message" is associated with a modicum of privacy. And the current Mastodon implementation does not provide much privacy at all for personal messages. As welcome as UX changes are, they would not change the underlying architectural issue, and might even increase the _appearance_ of those messages providing any actual meaningful privacy.
Let me know if you find that explanation needs more details. 😉
@jochenwolters That's a very clear explanation thank you. I don't think many apprecaite just how hard it is to add encryption properly and it's like going to take a while. As we already have PMs in the product and improving them would be very helpful, it seems like we shouldn't wait.
Part of why I'm asking is that here are MANY ways to use PMs, many of which do not require encryption at all. Of course it would be very nice to have. But I just want to call out, even with encryption, you likely want to be very careful using Mastodon for organizing as your profile and public posts would likely leak a tremendous amount of personal info.
Again, this doesn't mean we shouldn't do it, just that microblogging makes it hard to proprely protect your identity.
@scottjenson Thanks for the thoughtful response, Scott. I sincerely appreciate that! And I agree with everything you write.
Here's a little IxD detail in Mona 6 that's I find very useful. I hardly use the official Mastodon clients. So if they lack such a reminder, adding it should be a fairly minor effort with a huge upside in terms of setting the accurate security expectations with users.
@jochenwolters Agreed! These are the type of fixes I'd like to consider IN ADDITION to continuing to work on backend encryption
@scottjenson Not critical, as I wouldn’t expect it because of the current implementation.
If a future iteration of PMs would change that, it might as well be a good idea to communicate it explicitly in the UI, e.g. at the beginning of a new conversation. Basically the opposite of what WhatsApp does (see screenshot).
Also, if encryption means it’ll harder for third party apps, services,… to adopt PMs, then I feel like it’s definitely not worth the effort.
@scottjenson Don't really need encryption just for the DM edge-case. I only need to know where/for who exactly my message will pop up automatically, though.
Suggesting "encryption" exists in mastodon, how can one make sure it is interoperable with ActivityPub AND nobody gets it wrong and falsely assumes encryption is omnipresent, when it is absolutely not.
@mray Encryption is being explored by a FEP
Is the FEP public? I’ll love to check it out!
@scottjenson Interesting, seeing how other protocols got burned by adding encryption as an afterthought (XMPP, MAIL) I think we are still very very far away from having something comprehensive, reliable and usable. Unless that's a reality I'd shy away from promoting it unnecessarily loud. 🤷♂️
Encryption rocks though. I hope that FEP has lots of traction.
@mray But now you know why I'm asking. There is lots of energy around encryption but it's a very tricky thing to be done right. My point was simply that we start with some simple UX improvements and not wait for the encryption (given we already have private messages)
@scottjenson also dealing with encrypted chat inside the browser is extra spicy. I'd love to see people seriously tackling that, but I remain reserved. 😬
@scottjenson I'm pessimistic up to the point where you have to have to assume it will fail completely. Just as XMPP and MAIL failed.
The only encryption implementation with success were the approaches where the UX can be controlled centrally.
For MAIL there is #autocrypt now, it is astonishing of good it is – but email is still not encypted today.
XMPP/Jabber has OMEMO, but stillt struggles with client adoption and it isn't omnipresent.
Where it worked: #DeltaChat and #Signal both using a central library that can make sure encryption reliably lands at peoples fingertips.
@mray I so appreciate your concerns. It's actually why (personally, I'll add) I'm concerned why encryption may take a while (the Mastodon team is very thorough and would not release a rushed version of this) This is why my original post really had nothing to do with "should we add encryption" but was rather "while we're waiting can we at least make some improvements?"
@scottjenson My take (which seems to fly in the face of the zeitgeist) is that Mastodon is not meant foremost as a private messaging app. It is at its core, an *open, social* microposting platform. There are apps that are radically better suited for private and safe comms, and I am a huge proponent of letting things be true to themselves. When you try to shoehorn stuff into a system not intended to do that stuff, it ends poorly.
So, sure, DMs out of the timeline, but no Signal-like hardening.
@octothorpe Thank you! To be clear, I'm not against adding encryption to Mastodon but it would be rather different than what you get with Signal. Here is a simple example. Many people are quite public with their real name here on mastodon, that makes sense. But if you REALLY wanted to use an encrypted message you ikely wouldn't want to use your public name. So in many ways, encrypted messages by you very little (well,in some situations)
That's kind of my point, I don't think people really see the FULL JOURNEY necessary for encryption.
However, many have said "I just don't want to have to trust my admin. I just need it for privacy" and you know, that's a perfectly good reason and to be fair, has NOTHING to do with competing with Signal.
That's all I'm trying to do here, understand how and why it would be used.
@scottjenson I dig it. And yeah, the complications you implied are probably exactly the same I did (my post char limit is small)… which is why I shorthanded to ‘signal-like’.
But yeah, I get why folks may want it. I think it’s probably best to not encourage that behaviour in the app (because of how easily it could be accidentally borked, ex: public posting passwords). The notion being if you KNOW it’s not encrypted, you’re less likely to send sensitive material.
in 2026, gabe is absolutely right. a few years ago, i would've been the first one debating this position... but it's 2026.
@gabek @scottjenson
“It’s 2026” is about to be the final boss of product design:
Dev: Should we do this feature?
Me: It’s 2026, what do you think?
Dev: Say no more…
@by_caballero @gabek We've publicly announced we're working on encryption. It's a TON of backend work. It can proceed in parallel with UX work. It's not one vs the other. Especially as the UX work is FAR less than the encryption work
@scottjenson some of these are in the Mastodon roadmap!
https://blog.joinmastodon.org/2026/02/our-technical-direction/
@mapache Yes, I know! 😉 I'm not saying no I'm exploring when (as encryption will take longer than UX improvements
As long as there's a "hey, this isn't encrypted!" Kind of Disclaimer, I'm fine. If we wanted encryption, there's other apps or services. But, I don't want people to mistakingly share sensitive info on this platform.
That said, encryption in the future would be amazing, but I prefer other improvements not be blocked by that for the moment.
@scottjenson broadly, encryption for DMs on a social network isn't something I'd expect.
Would any of the proposed changes to DMs trigger age-verification requirements in the UK, Australia, etc?
@mia Honestly I hadn't even thought of that, thank you for bringing it up!
Yes, I need it.
Because I do not trust you, the admin.
I also don't trust those who will seize servers.
@katzenberger Fair enough, but can you tell me when you'd use it on Mastodon vs when you'd use it for Signal? I'm trying to understand if Mastodon, by implementing this is likely to replace Signal usage for many people? I don't think it will so I'm trying to understand WHY you'd need it in Mastodon when you just use an app that specializes in this.
Because "private" means "private", on whatever platform.
Platforms have different purposes. I'm not seeking for a Signal replacement, I just want the promise of "private" conversations to be kept. Like I'd expect it from any other platform that is speaking of "private" messages.
More pointedly, I would accept DMs from (and periodically check my inbox for) Mastodon but i would not give my unique and precious signal identifier to all of mastodon and all who crawl it @katzenberger @scottjenson
@by_caballero @katzenberger This is something that I have to admit a blindspot. There appear to be so many nuanced layers to "sending and encrypted message". For example, some just want to keep the admin from seeing stuff (that seems like the lowest level)
But at the highest level is for example protext organizing. I can't imagine ANYONE wanting to do that from a Mastodon account only because your profile and public posts likely leak a tremendous amount of personal info.
If you had a LOCKED DOWN account, sure it could work. My point is that I'm trying to understand these very different usages as we could naively asume we're good at one when we aren't. For example, I strongly feel that Signal very much still has a role here even if we do implement it correctly.
You know who's thought a lot about secure messaging? SWF's @mallory .
See also:
https://socialwebfoundation.org/2025/12/19/implementing-encrypted-messaging-over-activitypub/
@katzenberger Fair enough, I'm not arguing against that. It's just that encryption isn't easy and will take a long time. I'm using this as a 'research foil' to understand why people use Signal vs encrypted Mastodon PMs.
I totally get that people just want safety baked into everything, I'm not against that in any way. But it is very hard to do well.
I understand that, and if there is a roadmap that leads to having it, I'm happy with that.
It may also be worth considering a collaboration with those who have the expertise and are working on related ideas for the Fediverse already, like @soatok
@scottjenson Encryption would be very good for private mentions. The point of “private” is that it is private. If someone is notifying of a security related issue for example - no one else should see it. Not only is it against the description of the feature; it’s an actual problem because the feature implies a trust that should not be given.
@mattwilcox all fair points!
@mattwilcox My issue is simple: Should Mastodon replace Signal? Given how good it is, I'm trying to understand it's place in the world vs ours?
@scottjenson No. But if you offer “DMs” or “private mentions” you have to fulfil on that. You can not palm it off to other services. Nor do you need to replace other services. You just have to deliver on the implicit promise.
I think it’s unfair to assume users will know or find out that “here” DM/private acts differently to every other service using those terms.
@scottjenson it's great that you've shared this question. It's a good example of feature prioritization tradeoffs.
For me, encrypted DMs wouldn't matter in Mastodon. As a rule, I don't share things here privately that I wouldn't want to be made public.
... and that's mainly because (as you point out) DMs appear in the public timeline. It's such a confusing UI choice that I'm VERY careful about what I write in DMs here. 😜
@jarango exactly! For me PMs are a convenience. I don't personally need it. But there are folks working on it in a FEP but my understanding is that it is fediverse wide not just Mastodon (as it should be!)
Given how hard it'll be to do this I'll like to clean things up and not wait for the more secure option (especially if most use cases don't require it)
@scottjenson here's another way to put it: for me, unless DMs are shown separately from the public timeline, then the fact they're encrypted wouldn't make a difference. The dedicated DM space is the critical feature, encryption can follow.
@jarango My thinking exactly. My concern is that there are some peolple that really want it and I'm trying to suss out how important it is to them (and why) What I'm getting so far from this thread is quite the opposite.
@scottjenson I can imagine encryption would be a very important feature for lots of folks drawn to the Fediverse.
@jarango bingo, now you know what I'm kind of making a strong point to get a feeling about how strongly people actually feel about this.
My point is that encrypted communication is very valuable, but it's usage is quite distinct from microblogging. I'm trying to understand who needs it WITHIN Mastodon (vs just switching to an app that specializes in and likely will do a better job if I'm honest)
@scottjenson it probably should, lord knows what people would send; passwords, identity materials, tokens, etc
@scottjenson I think it would be fine, but I guess you'd still need to solve some design and architectural questions up front if you *know* you're going to do encryption in the end.
@neal yes! Good point. We already do PMs however so we'd start with fixing these
@scottjenson One thing that probably needs to go away is the ability to accidentally drag someone into a conversation by mentioning them. That flexibility is *dangerous* for private messages.
@neal OOOOOh, that's a cool point! Thank you. What are you suggesting, that PMs are ONLY 1:1?
As a related issue: replies to "followers only posts" being "my followers only" is a strange behavior.
I think if there was a "replies can only restrict the audience compared to the audience of the replied post, not expand it" constraint, that would solve both issues
@scottjenson I think that PMs should lock to who they are initiated with. That means the people tagged for that conversation when the PM is initialized are the only people who can be in the conversation. Further mentions *must not* expand the group.
I don't know if that means you should break the ability to do a private reply to a public message, but UX wise it might make sense to do so.
@neal I will be thinking ALOT about this comment. Thank you for explaining it. Very much appreciated.
@scottjenson I'm a fan of prioritizing the DM experience first.
wrt encryption, part of the challenge is how to interpret "private." Instead of the, "Who can see this?" default posture of Mastodon, this starts to ask something like, "Who cannot see this (beyond the addressed person/people)?"
@earth2marsh I'm not sure I follow, can you explain this default posture a bit more and what you'd like to see a bit more?
Deliver UX improvements first, technical improvements later. The law of low-hanging fruit.
Encrypted messaging would be nice to make this a place for social organising as the US and other countries become more authoritarian.
@scottjenson If messages were encrypted, I think it would be really important that there is a very clear distinction between encrypted and unencrypted posts. Using the same part of the UI for both encrypted and unencrypted messages with the only distinction being a hard to understand setting behind a button I think invites confusion as to what the precise security guarantees are.
@scottjenson I was actually just thinking about why private mentions are even needed when there are other options like email for private and sensitive discussions between folks. I guess I never truly understand why they are needed in a public social network in the first place? Just leftover from Twitter precedent?
@scottjenson
As critical as encrypted email.
(I realize this doesn't answer your question, but it's a very similar thing)
@scottjenson I think just knowing that the DMs are not encrypted is enough IMHO. If you want something encrypted use Signal.
@phillycodehound @scottjenson I love Signal, but there is something to be said for being about to communicate with fediverse people directly in the fediverse.
@phillycodehound @scottjenson Agree that Signal would cover it for most people, but some (like me) can't get a Signal account because we don't own a cellphone...
(I'm not saying that the numbers are large enough to justify adding it here, just pointing out that not everyone can use Signal even if we want to.)
@asmaloney @phillycodehound Fair enough, but there are other encrypted messaging apps other than Signal yes?
@scottjenson @phillycodehound Maybe there are, but that's where everyone I would want to communicate with are.
@phillycodehound @scottjenson I tend to agree with you. Not every platform really needs encryption, and given that Signal is already the gold standard for private messaging, going over there makes sense to me.
@crackhappy @phillycodehound Kind of where I'm coming from. I'm making this point a bit "in the open" not to say any decision is made, but to see if I'm missing something important.
@phillycodehound @scottjenson I was going to say that I pretty much feel the same, but on the other hand, Bluesky *kind of* has this feature now already?
Maybe something like this would work here as well rather than built-in?
sort of-- bsky is just verifying/confirming a self-attested Germ identifier. and no android yet, so only half of bsky users in the US and far less outside US.
@stefan @phillycodehound @scottjenson
@stefan
That's interesting! But it kind of begs the question how you're using encrypted communication. I get that you can launch this Germ app from within Bluesky as a convenience, that's cool, but if you're REALLY using encrypted communication, you're not going to be using it exclusively from Bluesky.
Others have said it but I'm thinking the venn diagram of people that need encrypted messaging (which is huge and valid) is quite distinct from people that need private mentions on a microblogging platform.
