#mastondon Friends!
-
#mastondon Friends!
There is a TON of improvements we could make to Private Mentions (often called DMs on other platforms) e.g.
* getting them out of the public timeline
* Having a stronger notification tied to the Private Mention tab
* (amount other things)But here is my MAIN question: How critical is it that these message are encrypted? I'm not against encryption! It's just complex and will take time. If we were to make some UX changes as a first pass WITHOUT encryption would you be OK with that (at least for now?)
If you MUST have encryption, that's fine, please do me the favor of replying explaining why you need it.
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.
-
#mastondon Friends!
There is a TON of improvements we could make to Private Mentions (often called DMs on other platforms) e.g.
* getting them out of the public timeline
* Having a stronger notification tied to the Private Mention tab
* (amount other things)But here is my MAIN question: How critical is it that these message are encrypted? I'm not against encryption! It's just complex and will take time. If we were to make some UX changes as a first pass WITHOUT encryption would you be OK with that (at least for now?)
If you MUST have encryption, that's fine, please do me the favor of replying explaining why you need it.
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.
-
#mastondon Friends!
There is a TON of improvements we could make to Private Mentions (often called DMs on other platforms) e.g.
* getting them out of the public timeline
* Having a stronger notification tied to the Private Mention tab
* (amount other things)But here is my MAIN question: How critical is it that these message are encrypted? I'm not against encryption! It's just complex and will take time. If we were to make some UX changes as a first pass WITHOUT encryption would you be OK with that (at least for now?)
If you MUST have encryption, that's fine, please do me the favor of replying explaining why you need it.
@scottjenson 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. -
#mastondon Friends!
There is a TON of improvements we could make to Private Mentions (often called DMs on other platforms) e.g.
* getting them out of the public timeline
* Having a stronger notification tied to the Private Mention tab
* (amount other things)But here is my MAIN question: How critical is it that these message are encrypted? I'm not against encryption! It's just complex and will take time. If we were to make some UX changes as a first pass WITHOUT encryption would you be OK with that (at least for now?)
If you MUST have encryption, that's fine, please do me the favor of replying explaining why you need it.
@scottjenson I just don't want others to be able to read personal conversations.
However, since I am using Mastodon without e2ee today, I'll survive longer without it by putting contact url into the bio.
-
@scottjenson 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.
-
@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 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:
- each client creates its own key, encrypted messages now need to be encrypted with multiple keys and the new clients don't have chat history (this could be mitigated by having existing clients with the decrypted messages send them to the server with the new key)
- there is some sort of handshake when registering a new client, that passes the private key from a registered client to the new one
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. -
@scottjenson 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:
- each client creates its own key, encrypted messages now need to be encrypted with multiple keys and the new clients don't have chat history (this could be mitigated by having existing clients with the decrypted messages send them to the server with the new key)
- there is some sort of handshake when registering a new client, that passes the private key from a registered client to the new one
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.
-
@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 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.
-
@scottjenson 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.
-
#mastondon Friends!
There is a TON of improvements we could make to Private Mentions (often called DMs on other platforms) e.g.
* getting them out of the public timeline
* Having a stronger notification tied to the Private Mention tab
* (amount other things)But here is my MAIN question: How critical is it that these message are encrypted? I'm not against encryption! It's just complex and will take time. If we were to make some UX changes as a first pass WITHOUT encryption would you be OK with that (at least for now?)
If you MUST have encryption, that's fine, please do me the favor of replying explaining why you need it.
@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.
