Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

is_direct field on /createRoom body does not automatically mark the room as a DM #1692

Open
DMRobertson opened this issue Dec 5, 2023 · 4 comments
Labels
wart A point where the protocol is inconsistent or inelegant

Comments

@DMRobertson
Copy link
Contributor

Link to problem area: https://spec.matrix.org/v1.9/client-server-api/#creation and https://spec.matrix.org/v1.9/client-server-api/#direct-messaging

Issue
I naively expected that passing this flag to /createRoom would automatically mark the created room as a DM in the creator's account data. This seems not to be the case: the referenced bits of the spec mainly talk about propagating the is_direct flag to invitees.

(Might be appropriate to close this as WONTFIX if this doesn't bother today's clients, and if canonical DMs will fix it.)

@DMRobertson DMRobertson added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Dec 5, 2023
@DMRobertson
Copy link
Contributor Author

(I did search for an issue, but couldn't find anything matching is_direct.)

@DMRobertson DMRobertson changed the title is_direct: field on /createRoom body does not automatically mark the room as a DM is_direct field on /createRoom body does not automatically mark the room as a DM Dec 5, 2023
@richvdh
Copy link
Member

richvdh commented Dec 5, 2023

The spec is fairly explicit that the clients have to do this themselves:

The invitee’s client may use the is_direct flag in the m.room.member event to automatically mark the room as a direct chat but this is not required: it may for example, prompt the user, or ignore the flag altogether.

Both the inviting client and the invitee’s client should record the fact that the room is a direct chat by storing an m.direct event in the account data using /user/<user_id>/account_data/.

@DMRobertson
Copy link
Contributor Author

Sure; I'm more complaining that this is a bit of a crap situation if you're expecting to do read the DM flag. (There's an extra RTT and a transitory flicker where you've asked for a DM and got something but not a DM yet.)

The context this came up on is the sliding sync proxy: we only want to consider rooms with the DM flag to inherit members' avatars: element-hq/element-x-ios#2003 (comment)

@richvdh
Copy link
Member

richvdh commented Dec 5, 2023

fair enough. It's probably something that could be changed.

Waiting for canonical DMs is likely to be a long wait.

DMRobertson pushed a commit to matrix-org/sliding-sync that referenced this issue Dec 5, 2023
@turt2live turt2live added wart A point where the protocol is inconsistent or inelegant and removed clarification An area where the expected behaviour is understood, but the spec could do with being more explicit labels Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wart A point where the protocol is inconsistent or inelegant
Projects
None yet
Development

No branches or pull requests

3 participants