Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct Message: Manage encrypted DM in case of invite by email #372

Closed
giomfo opened this issue May 30, 2022 · 5 comments
Closed

Direct Message: Manage encrypted DM in case of invite by email #372

giomfo opened this issue May 30, 2022 · 5 comments

Comments

@giomfo
Copy link
Member

giomfo commented May 30, 2022

Currently this is possible to start a new DM by filling an email address.

The resulting DM is an unencrypted room (even if the encryption should be enabled by default according to the HS well-known configuration) because there is no way to encrypt message in this room until an actual matrix account has joined the DM:
image

The purpose is to let the end user start sending messages before the invited contact creates the contact and joins, but there is some concerns:

  • we run the risk to let people using an unencrypted DM without being aware of that
  • matrix.org allows us to create unencrypted DM, but some HS may force the encryption in the created DM. The user experience would not be good then

I would suggest here creating encrypted DM when the end user starts a DM by selecting an email address, as soon as the encryption is supposed to be enabled by default (well-known HS configuration). I would hide the resulting DM until the third party invite is accepted by a matrix account. The DM would be displayed in the people section only when the DM would have at least 2 members.

For that we should:

  • prevent the end user from selecting multiple email addresses in the start DM dialog. I would limit the UI to only one email, and rename the button "Go" (or create) with "Invite"
  • prevent the end user from selecting email address(es) and matrix id (s) at the same time (currently this is possible in Element)
@gaelledel gaelledel self-assigned this May 30, 2022
@gaelledel
Copy link

Currently in Element DMs can be group DMs so the logic here around blocking several email users will not work

@estellecomment
Copy link

Hi @gaelledel , here is a new proposal that can hopefully be a better fit.

When a user creates a DM and invites others by email, and encryption is activated, we risk having undecryptable messages for the users that have not joined yet.
To avoid this, a simple solution is to block the message-writing box until the risk is gone. That is, until all the users have created an account and joined the DM.
This works with any number of users in the DM.

Proposed (ugly) mockups :
These mockups are temporary, for the sake of discussion.
Example situation : a user starts a DM by inviting two other users by email.

Step 1 - Before the two invited users have created their account : message bar is disabled, replaced by an explanatory message (inspired by the interface for previewing a room, which also blocks writing messages)
blocked_DM_1

Step 2 - One user has created their account, still waiting for the 2nd user :
blocked_DM_2

Step 3 - When both users have created their account, the risk of undecryptable messages is over : we go back to the normal DM interface, with a message bar enabled.

Impact on Element-web
In element-web, when invited users don't have an account yet, the created DM is NOT encrypted. So there is no risk of undecryptable messages. The problematic situation appears only when the server forces encryption for all DMs (it is the case in Tchap, our customized version).
So in practice for a user on element-web on the matrix.org server, the situation described above will never happen. No visible changes for the element-web user.

Let us know if that sounds acceptable, and let's discuss further if it's not. Thanks !

@jdauphant
Copy link

Hello @gaelledel 👋 did you had time to take a look at our proposition ?

@gaelledel
Copy link

Tchap ticket tchapgouv/tchap-web-v4#63

@gaelledel
Copy link

@jdauphant @estellecomment Thank you, I am taking note of your suggestions. Will be tackling this sometime this week

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

5 participants