Feat : Hide new DM until both user accounts are created ("U no write befor fren join")

[estellecomment]

Description of the problem :
User1 has an account. User2 does not.
User1 invites user2 by email into a DM. DMs in Tchap are always encrypted.
User1 starts writes a message. It is encrypted, but user2's account does not exist yet.
User2 creates their account and joins the DM. They cannot decrypt the message.
-> we need to stop user1 from writing before user2 has joined, to avoid the creation of un-decryptable messages.

Screenshots :
User1 sees:

User2 sees:

Discussion on how to add this feature in Tartine.
Details : https://www.notion.so/mercurial-timer-ec4/f0b25ecf9b3145899090a3f82db9474a?v=f7f59371ae05431980c5e02ae4683552

So far, Tartine is based on element-web 1.10.10.

[estellecomment]

Rebasing Tartine to element-web 1.10.14 (PR #62) we see :

User1 sees :

User2 sees :

Less weird errors, but doesn't solve the problem either.

[estellecomment]

Question : for the user experience, is it better or worse to display the DM but block the writing (with a message explaining why you can't write), instead of not displaying the DM at all ?

[estellecomment]

Interesting files to look at in element-web : MessageComposer.tsx (the component where the user types text) and RoomView.tsx (the middle part of the screen, which displays all the messages for the room, and contains the MessageComposer)

Possible implementation :

• Create a BlockedMessageComposer which displays an explanation message (“waiting for other user to join, you will be notified”) Work with design to show something non-irritating yet clear.
• In RoomView where we build the MessageComposer, add a check for isEncrypted && isDM && OtherUserHasNotJoinedYet, and in that case display the BlockedMessageComposer instead of the MessageComposer.
  • How do we know the room is encrypted ?
    • Event : m.room.encryption
    • In RoomView we can use this.context.isRoomEncrypted(roomId)
  • How do we know the room is a DM ?
    • Events : m.room.encryption and im.vector.room.access_rules (custom tchap event)
    • Boolean to check :isRoomEncrypted && (roomAccessRules == DIRECT || (roomAccessRules == null && roomSummary.isDirect) )
    • Reference implementation in Android client : https://github.com/tchapgouv/tchap-android/blob/develop/vector/src/main/java/fr/gouv/tchap/core/utils/RoomUtils.kt#L31
  • How do we know the other user has not joined ?
    • In RoomView : room.getJoinedMemberCount() or room.getJoinedMembers()
• When other user joins, trigger a notification and change to normal MessageComposer.
  • How do we listen to the other user joining ?
    • RoomView has updateRoomMembers called by onRoomStateUpdate
  • How to trigger a notification ?
    • todo
• If necessary, tweak the display name of the room, if it looks weird before the full DM setup.
• If necessary, add an icon next to the room name (or some other equivalent change) to show that the room exists but is not ready yet.

[giomfo]

@estellecomment FYI element-hq/element-meta#372 is the related issue where I discuss about this topic with Element team

[estellecomment]

Proposed interface which still allows for multi-user DM (which is a feature in Element, but not allowed in Tchap). This is not final, it's a just a bunch of copy-pasted screenshots :)

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

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

When both users have created their account, we go back to the normal DM interface, with a message bar enabled.

[estellecomment]

@areox-net

[areox-net]

@estellecomment I think the idea is good. The message could also simply be "Waiting for .... to accept invitation".
Long text may not fit on mobile.

[estellecomment]

Note : this would cause no visible changes for users of element-web, because element-web does not create encrypted DMs in this case.