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

[giomfo]

Your use case

Context sum up

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:

The purpose is to let the end user start sending messages before the invited contact creates theirs account 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

What would you like to do?

After discussing with Design team, we converged to the following solution:

• When the HS promotes the encryption (via the well-known endpoint), the DM will be created by enabling the encryption. The chat composer will be disabled until a matrix account is created by using the invited email
• In order to be able to name correctly the resulting room, only one email address will be allowed at once. The created DM will be added to the m.direct dictionary by using the email as key. The Element clients will then able to add this DM in the right people section and name it with the full email address

Here are the suggested design:

Figma: https://www.figma.com/file/OvsSONqAyabcUDYp8tnEs6/Start-a-DM?node-id=1373%3A49380

Have you considered any alternatives?

No response

Additional context

We plan to work on a PR for this in the following weeks

[t3chguy]

The created DM will be added to the m.direct dictionary by using the email as key.

Is there an MSC to allow this? The spec says the keys are MXIDs

https://spec.matrix.org/v1.3/client-server-api/#mdirect

[weeman1337]

At least on web, e-mail-addresses are listed in m.direct. We are probably not spec-compliant there.

[turt2live]

That is indeed a bug/spec violation. Previously reported as #7484 but closed due to lack of traffic/known causes.

[t3chguy]

@weeman1337 was web the only client you ever used on the account? m.direct is obviously shared across all your devices ever

[weeman1337]

Checked on Android. Same behaviour there.

[giomfo]

We agree to write an MSC for supporting email addresses in m.direct event. This would at least clarify what is implemented in the current Element clients.

We should replace the email address with a mxid once known, like we did in Element-Android here

[t3chguy]

Small reminder that m.direct is on its way out with canonical DMs