Only create DM room when first message is sent

[turt2live]

Instead of eagerly creating a room, only create the room when a message is sent. This could also help us use the room list search as a way to start DMs if we wanted

[t3chguy]

I am certain this is a dup but cannot find it :'(

[jakewb-b]

Since my issue was closed as a duplicate, copying the specific requirement here, and changing title to be a little more descriptive.

• As a user sending a DM to someone I do not have an active DM conversation with
• I want the room to be created only when I first send a message (text, image or voice)
• So that the recipient receives the invite only when there is a message in the room

[gaelledel]

@turt2live @t3chguy @giomfo
I am updating the behaviour for Starting a DM. What changes is the mentioned above: We're only sending the invitation when user A (sender) sends a message to user B (receiver).
I would also be keen to allow message previews for user B when receiving an invitation see below.

Is this possible? For encrypted rooms, we could have the first few words with the rest encrypted.
This would help minimise spam requests and make user B more confident in starting the DM.

Thanks

[gaelledel]

See the flows here https://www.figma.com/file/OvsSONqAyabcUDYp8tnEs6/Start-a-Chat?node-id=0%3A1

[MurzNN]

@gaelledel maybe also add a "Mutual rooms with this user" block, which will show list of rooms (and spaces?) where both of users (current user and invite owner) are members?

This should be very useful to understand from which source this person founds you. Because very often I receive invites from strange persons, and before accepting - need to manually research in which rooms/spaces I see them before.

[turt2live]

The message preview is difficult, but we do have a concept of "invite reason" we could display.

I'd be worried that the first message preview isn't all that helpful (and easy to bypass for spamming), so would encourage us to look into peeking support on invited rooms instead - a much harder technical feat.

[gaelledel]

@MurzNN Yes, that's a good point thank you. Unsure if we'd be able to pull this info at the stage of the invite though. @turt2live might know actually.

Regarding:

The message preview is difficult, but we do have a concept of "invite reason" we could display.

I'd be worried that the first message preview isn't all that helpful (and easy to bypass for spamming), so would encourage us to look into peeking support on invited rooms instead - a much harder technical feat.

Thanks for the feedback. Could you expand on the "invite reason" concept?

[t3chguy]

The mutual rooms suggestion is already WIP matrix-org/matrix-react-sdk#4897

[gaelledel]

Good to know indeed thanks @t3chguy

[kittykat]

@gaelledel would it make sense to change the behaviour already to create room on first message while we wait for mutual rooms and figure out how to do the message preview/peeking?

[gaelledel]

Yes this is the plan. The designs have changed since to accommodate for this. We will be showing common rooms and spaces instead.

[giomfo]

The same request change has been described in android-element and ios-element.
We will use this issue to track the change in Element-web

When the user wants to select someone to DM, the current UI is:

• When the user presses 'Go', after selecting Corey:
  • if there is already a DM with Corey : open the DM
  • if there isn't DM with Corey, instead of the room being created (and Corey being invited to an empty room), The user sees the following interface with the composer (the room has not been created).

• If the user doesn’t send a message ( = navigate to another room) no room is created. The user has to start again.
• If the user does send a message, then the DM room is created by inviting Corey and the message is sent. The room exists and is displayed in the people section

Additional Requests

• If several contacts have been selected in the picker before clicking on the Go option. The interface is adapte. I provide here the mobile design for this use case:

• If the user selects at least one email address in the selected contact list, the resulting DM will be unencrypted. We have to hide the following tile in the interface

[erkinalp]

Multiple rooms with same members are possible in the protocol level, hence Element should not make this impossible.

[turt2live]

@erkinalp that's a different issue.

[ShadowJonathan]

(matrix-org/matrix-react-sdk#8612 seems to be relevant to this effort.)

[giomfo]

@weeman1337 FYI we have to apply the same process (create DM only on first message) when the end user decides to start a DM from the room member details screen (by clicking on "Message" option), whereas the DM is not existing yet.

[weeman1337]

Plan for community testing session:

Setup:

• You should have at least two Matrix accounts available and logged in at the same time.
• Leave the DM room(s) with all accounts after each test.
• To perform the e-mail test cases some spare e-mail addresses or a „+“ alias capable account is required.
  If you don't have those you can skip the e-mail tests.

Title	Description
Note	The following tests should target one DM partner. The expected result is that the partner got the invite, sees the message after he joined and that the room is end-to-end encrypted.
Start DM with text message	Start a DM by typing a simple text message
Start DM with one attachment	Start a DM by sending a file using the attachment button in message composer
Start DM with multiple attachments	Start a DM by sending multiple files using the attachment button in message composer
Start DM with attachment from clipboard	Start a DM by sending a file pasted from the clipboard
Start DM with one attachment from drag & drop	Start a DM by sending one file pasted to the room
Start DM with multiple attachments from drag & drop	Start a DM by sending multiple files dragged to the room
Start DM with poll	Start a DM by sending a poll
Start DM with sticker	Start a DM by sending a sticker
Start DM with location share	Start a DM by sharing your location
Start DM with live location share	Start a DM by sharing your live location
Start DM with voice message	Start a DM by sending a voice message
Note	The following tests can be done by sending text message
Start DM from „People +“	Start a DM using the „+“ from the sidebar people section
Start DM from room member list	Start a DM using the „Message“ button in a room member list
Start DM from spotlight search	Start a DM by searching a user in the spotlight search (Ctrl + K or click into the top left search field)
Start DM with two MXID users	Start a DM by inviting two users having a matrix account
Start DM with e-mail user	Start a DM by inviting an e-mail address. After the other side joined the room should not be encrypted.
Start DM with one MXID user and one e-mail user	Start a DM by inviting two users: one with MXID and another by e-mail. After all have joined the room should not be encrypted.
Perform a verification without having a DM room	Let two users, which don't have a DM yet, verify each other. This can be triggered from a member list of a room that both have joined.

[Half-Shot]

There is a slight issue here that it's not safe to assume that just because you can start a DM with someone, the DM will be permitted by the remote side. E.g.

• Lots of puppeted bridges will leave a DM if the Matrix user isn't connected to the bridged service (i.e. you're not logged into Slack, you cannot DM slack users)
• Some users will have their own mechanisms for automatically blocking DMs for users they do not already know.

This means that with this features, users could end up possibly typing a fairly lengthy message only to be told they cannot talk to the remote user. There is also a slightly more problematic side in that it's very likely some services will have race conditions between a invite and a message being handled concurrently (though, I am not sure how the proposed implementation works -> maybe messages are only sent upon join?)

This doesn't mean the feature isn't a good one, but it will degrade the experience for some users.

[giomfo]

@Half-Shot the potential race conditions problematic between the invite and the message has been taken into account by the implementation

About your first point, the contact picker should be improved to prevent you from selecting people you could not talk to. Can you provide some criteria/conditions to filter the contacts list?