A DM is recognised here only by is_direct on the membership event - rooms.rs:157, read off an invite. The m.direct account data event, which is where Matrix actually keeps the list, is never read and never written: the only mention of it in the backend is a comment in directory.rs:3.
So a DM started from Element, or started here, is a DM in one client and an ordinary room in the other. It lands outside the DM group in the rail, is named after the room rather than the person, and stops being sortable with the rest of the conversations.
Both directions are needed: read m.direct to learn what the account already considers a DM, and write it when openMatrixDm creates one, so the other clients agree.
A DM is recognised here only by `is_direct` on the membership event - `rooms.rs:157`, read off an invite. The `m.direct` account data event, which is where Matrix actually keeps the list, is never read and never written: the only mention of it in the backend is a comment in `directory.rs:3`.
So a DM started from Element, or started here, is a DM in one client and an ordinary room in the other. It lands outside the DM group in the rail, is named after the room rather than the person, and stops being sortable with the rest of the conversations.
Both directions are needed: read `m.direct` to learn what the account already considers a DM, and write it when `openMatrixDm` creates one, so the other clients agree.
Salastil
added the bug label 2026-09-13 11:59:31 -04:00
m.direct is read at connect and followed as it changes, and written on the two occasions a DM comes into being: opening one from here, and accepting an invitation marked is_direct — the invitee has to write that second one, since the inviter cannot touch somebody else's account data. Both are read-modify-write against the server's copy, because account data is replaced whole and writing only what this client knows would un-DM every other conversation on every device.
derive_room_info now takes the account's own answer, which outranks the member count in both directions: a DM can have three people in it, and a two-person room need not be one. The count stays as the fallback for an account whose list has never been written by any client. Name and kind are decided separately, so a named DM keeps its name and still files with the conversations — which is what Element does.
The live probe found seven conversations in this account's m.direct, every one of which was showing here as an ordinary room.
Finished.
`m.direct` is read at connect and followed as it changes, and written on the two occasions a DM comes into being: opening one from here, and accepting an invitation marked `is_direct` — the invitee has to write that second one, since the inviter cannot touch somebody else's account data. Both are read-modify-write against the server's copy, because account data is replaced whole and writing only what this client knows would un-DM every other conversation on every device.
`derive_room_info` now takes the account's own answer, which outranks the member count in both directions: a DM can have three people in it, and a two-person room need not be one. The count stays as the fallback for an account whose list has never been written by any client. Name and kind are decided separately, so a named DM keeps its name and still files with the conversations — which is what Element does.
The live probe found **seven conversations** in this account's `m.direct`, every one of which was showing here as an ordinary room.
[411b661](https://git.salastil.com/Salastil/nobilis/commit/411b661)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
A DM is recognised here only by
is_directon the membership event -rooms.rs:157, read off an invite. Them.directaccount data event, which is where Matrix actually keeps the list, is never read and never written: the only mention of it in the backend is a comment indirectory.rs:3.So a DM started from Element, or started here, is a DM in one client and an ordinary room in the other. It lands outside the DM group in the rail, is named after the room rather than the person, and stops being sortable with the rest of the conversations.
Both directions are needed: read
m.directto learn what the account already considers a DM, and write it whenopenMatrixDmcreates one, so the other clients agree.Finished.
m.directis read at connect and followed as it changes, and written on the two occasions a DM comes into being: opening one from here, and accepting an invitation markedis_direct— the invitee has to write that second one, since the inviter cannot touch somebody else's account data. Both are read-modify-write against the server's copy, because account data is replaced whole and writing only what this client knows would un-DM every other conversation on every device.derive_room_infonow takes the account's own answer, which outranks the member count in both directions: a DM can have three people in it, and a two-person room need not be one. The count stays as the fallback for an account whose list has never been written by any client. Name and kind are decided separately, so a named DM keeps its name and still files with the conversations — which is what Element does.The live probe found seven conversations in this account's
m.direct, every one of which was showing here as an ordinary room.411b661