Post
@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 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.
Install bonfire.cafe
Get the full app experience
