search

hifi / heisenbridge

a bouncer-style Matrix IRC bridge
MIT License
244 stars 34 forks source link

Create private chats with the is_direct flag #259

Open Kritzefitz opened 1 year ago

Kritzefitz commented 1 year ago

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.

hifi commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.