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

Create private chats with the is_direct flag #259

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Kritzefitz
Copy link

This changes the creation logic for private rooms to use the is_direct flag, so the room will be correctly recognized as a direct chat. To prevent the created room from being recognized as a private chat with the bridge user, we create the room as the irc user and then invite the real user and bridge user into the room and change the power levels to give power to the bridge user and take it from the irc user. This should leave the room in the same state after creation as before the change, but the initial invite to the real user is sent from the irc user and not the bridge user. This should cause clients to correctly recognize the irc user as the direct chat partner instead of the bridge user. This works correctly on element web, though I have not tested the behavior in other clients.

To ensure that users' client will determine the correct user as the
direct-chat partner, we let the IRC puppet user create the chat room
and send the invitation to the user.
@hifi
Copy link
Owner

hifi commented Jul 18, 2023

Can you leave your main control room and rejoin it by creating a DM with Heisenbridge? The reason why it was never enabled was that when a room is considered direct creating a new DM would just open an existing room blocking it completely from talking with Heisenbridge again from some clients, including Element.

@Kritzefitz
Copy link
Author

Can you leave your main control room and rejoin it by creating a DM with Heisenbridge?

Yes, this seems to work for me. The way I tested was:

  1. query some user (e.g. lambdabot on libera) (element recognizes the created room as a dm with lambdabot)
  2. close the dm with the bridge user
  3. open a new dm with the bridge user and type status a first message (element apparently only creates a dm room on first message)
  4. the message is sent succesfully and an appropriate status response is returned.

@Kritzefitz
Copy link
Author

I guess this would be quite risky to merge, without thoroughly testing the behavior on various clients. What do you think about hiding this behavior behind a per-user setting? That way the impact of undesired client behavior can be mitigated by just not switching the feature on. Though I guess it might still lead to unpleasant situations, if a user is locked out of the main control room as in your scenario and then unable to switch the feature off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants