You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suggest to enable a setting in dendrite.yaml to have all DMs between users on the local server unencrypted by default. DMs to users on other servers should be encrypted by default.
Rationale: Chats between local users are only stored on the local server and therefore can be protected on the server level. Encryption adds unnecessary overhead (e.g. using multiple devices) and also makes it impossible to audit/document chats for companies.
The text was updated successfully, but these errors were encountered:
My assumption was that Dendrite would be the best to understand whether this the DM is created between two local users. The client might not know whether the user is local or via federation. My proposal would not be to show in the UI the chat is encrypted while in reality it is not. Instead I suggest a configuration setting (e.g. overwrite encryption request for local DMs) that converts a request from a client to create an unencrypted DM if both users are local on the server. The client would then show that the DM is unencrypted.
This doesn't make much sense. End-to-end encryption makes sure only the sender and the reciever can write/read messages. So not even your homeserver should read/modify your messages. That isn't unnecessary overhead.
Also from my understanding this is not a server related option.
Description:
I suggest to enable a setting in dendrite.yaml to have all DMs between users on the local server unencrypted by default. DMs to users on other servers should be encrypted by default.
Rationale: Chats between local users are only stored on the local server and therefore can be protected on the server level. Encryption adds unnecessary overhead (e.g. using multiple devices) and also makes it impossible to audit/document chats for companies.
The text was updated successfully, but these errors were encountered: