DM list: one row per person when you have several DM rooms with them #99

Open
opened 2026-10-07 23:36:15 +00:00 by robocub · 0 comments
Member

Split out of #97 (operator 10-07: do this sooner; Saved messages goes on ice).

The problem

You can end up with more than one DM room with the same person: both sides press "Message" at the same time, a client crashes halfway through creating one, an old DM was left and a new one made, a bridge makes its own, or a room was upgraded (upstream Commet #597 is the room-upgrade case).

Today (testing a1a21432):

  • The DM list (directMessageRooms) is one row per room. Two DM rooms with Alice show two identical "Alice" rows.
  • "Message" on someone's profile (user_profile.dart openDirectMessage) opens existingRooms.first, which depends on list order.
  • The SDK's startDirectChat / getDirectChatFromUserId pick the room with the newest message. So the profile button and the SDK can open different rooms.

Proposal

  • One row per person in the DM list, keyed by getDirectMessagePartnerId (the m.direct user ID). The row opens the room with the newest activity. Unread and highlight counts add up across that person's rooms; the row sorts by the newest of them.
  • If there's more than one room, the row shows a small count. Expanding it lists each room with its name, last message, created date, and whether it's encrypted.
  • Profile "Message" uses the same rule (newest activity), so every path opens the same room.
  • Tombstoned rooms (upgraded, with a successor you've joined) are hidden from the group. This covers upstream #597 for DMs.
  • Group DMs (3+ people) and rooms with no partner stay as their own rows.
  • Later, optional: a "Tidy up" action that posts a pointer in the old room ("continued in …") and removes it from m.direct. Matrix can't merge history, so that's the closest we can get.

The data model stays the same; this changes the list, the profile and the quick switcher. Notifications per room stay as they are.

Tests

Unit tests on the grouping (two rooms for one partner, newest wins, counts add up, tombstoned predecessor hidden, group DM untouched), plus a widget test for the expanded row.

Open questions

  • Should the expanded list sit in the DM row, on the person's profile, or both?
Split out of #97 (operator 10-07: do this sooner; Saved messages goes on ice). ## The problem You can end up with more than one DM room with the same person: both sides press "Message" at the same time, a client crashes halfway through creating one, an old DM was left and a new one made, a bridge makes its own, or a room was upgraded (upstream Commet #597 is the room-upgrade case). Today (testing `a1a21432`): - The DM list (`directMessageRooms`) is **one row per room**. Two DM rooms with Alice show two identical "Alice" rows. - "Message" on someone's profile (`user_profile.dart` `openDirectMessage`) opens `existingRooms.first`, which depends on list order. - The SDK's `startDirectChat` / `getDirectChatFromUserId` pick the room with the **newest message**. So the profile button and the SDK can open different rooms. ## Proposal - **One row per person** in the DM list, keyed by `getDirectMessagePartnerId` (the `m.direct` user ID). The row opens the room with the newest activity. Unread and highlight counts add up across that person's rooms; the row sorts by the newest of them. - If there's more than one room, the row shows a small count. Expanding it lists each room with its name, last message, created date, and whether it's encrypted. - **Profile "Message"** uses the same rule (newest activity), so every path opens the same room. - **Tombstoned rooms** (upgraded, with a successor you've joined) are hidden from the group. This covers upstream #597 for DMs. - Group DMs (3+ people) and rooms with no partner stay as their own rows. - Later, optional: a "Tidy up" action that posts a pointer in the old room ("continued in …") and removes it from `m.direct`. Matrix can't merge history, so that's the closest we can get. The data model stays the same; this changes the list, the profile and the quick switcher. Notifications per room stay as they are. ## Tests Unit tests on the grouping (two rooms for one partner, newest wins, counts add up, tombstoned predecessor hidden, group DM untouched), plus a widget test for the expanded row. ## Open questions - Should the expanded list sit in the DM row, on the person's profile, or both?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
nether/vommet#99
No description provided.