Control and private rooms as direct

[Peetz0r]

As title says :)

[hifi]

I said this on Matrix but I'll put it up here as a reference as well: Element got confused when you had multiple DMs with the same user so this was reverted in the current design. If this can be tested not to cause the same issues then I'm okay with the merge.

[neocturne]

I said this on Matrix but I'll put it up here as a reference as well: Element got confused when you had multiple DMs with the same user so this was reverted in the current design. If this can be tested not to cause the same issues then I'm okay with the merge.

This should only affect control rooms, right? Having the change for private rooms would already be a great improvement IMO.

[hifi]

It's not only just control rooms IIRC. I'm fine with merging this if the behavior I described does not definitely happen. AKA you can open multiple DMs with IRC puppets and multiple network rooms without an issue. Close control room and reopen it while having all of those around etc.

I saw it happen with Element web originally and I couldn't reopen some room myself (probably control room) because I already had a room with is_direct set with the bridge. I think I had a network room open and I closed the control room and tried to reopen it.

[neocturne]

Is there a reason why the "heisenbridge" user needs to be in the private rooms at all? Would it be an option to perform all actions done through "heisenbridge" through the puppet you're chatting with instead, so private rooms can become regular direct message rooms?

[hifi]

The bridge is there for design reasons. It doesn't have a state database so it fetches the current state from the homeserver and the only reasonable way to determine if a room is relevant is to get the rooms the bridge itself is in.

I wouldn't hold my breath for this to change soon if ever.

[neocturne]

The bridge is there for design reasons. It doesn't have a state database so it fetches the current state from the homeserver and the only reasonable way to determine if a room is relevant is to get the rooms the bridge itself is in.

I understand that this is the current design. What I'm wondering is whether it would be possible to move the responsibilities of the bridge user to the puppet user (for private rooms), as both are ultimately controlled by the bridge.

[sergaderg]

Just as an additional data point, in element, you can force a room to be a DM vs not, via the /converttodm and /converttoroom commands. I'm not sure if converting a DM back to a room solves whatever buggy behavior was encountered before, but I thought it would also be worth mentioning here for folks who find this and want to manually convert some of their conversations.

[hifi]

Now I remember why Element didn't work correctly. If you already had a DM room with the bot you couldn't create a new chat (control room) as it would just reopen an existing DM where you two are the only participants.

So it works just fine if you never leave the main control room but if you do then you can't reopen it. If there was a way to tag such room as "not a real DM" it would solve this.