Disable invite and admin powers in direct chat

[scruloose]

Is your suggestion related to a problem? Please describe.
It seems couterintuitive and confusing for a direct chat to implement admin powers and the ability to invite other users:

• Kick, ban, mute, etc make no sense in a one-to-one chat: either party can just leave the conversation if they don't want to talk to the one and only other participant.
• New users are unlikely to expect a direct chat to have a setting for whether to allow newcomers to see the prior history, so it seems like this counter-intuitive behaviour could lead to unexpected privacy-breaching effects when one party assumes that a direct chat is just a direct chat but then the other party invites someone new in. Oops!
• For anyone considering Matrix/Riot as a replacement for SMS or Signal (shoutout to the Librem 5!), the confusing blurring-together of direct messaging and group chat rooms may be an obstacle.

Describe the solution you'd like
Honestly, I think the Matrix protocol should disable both inviting additional users and the whole admin powers framework in a direct chat between two users. But at least, can we throw a "Do you really want to convert this direct chat to a group room?" message when someone clicks the invite button in a direct chat? And include a warning about the prior history, if the current setting is to allow new users to see it?

Describe alternatives you've considered
I gather that the current behaviour is that the "direct chat" is converted into a "group chat room" when a third party joins. I have to admit that I don't see why that would ever be the expected or desirable way to do that, as opposed to creating a new room if I want to chat with more than one other user in one place.

Additional context
As a side-effect, I think disallowing inviting additional users to a group chat would take care of issue element-hq/element-web#9614 too.

[dud1337]

Disabling invite might be overkill. Otherwise, agreed. I've seen people have multiple matrix accounts and invite them all to the same "DM" with another user. Or occasionally adding a bot like giphy (not that I consider that secure). to DMs. In that case, a kick might be useful.

[tatarenko]

It would be great to have behavior similar to Skype:
When you in DM trying to invite more people in it, app creates new room for 3 people, join original 2 persons automatically and switch focus to this new room with empty history, 3d one is invited to this room and they wait him there.
Current behavior leads to misunderstanding for our users - you have DM with like 1 year history with person, you invite colleague for some help, you find out yourself useless in this new conversation, you leave the room and delete it from you contact list and you lost those 1 year DM history but it is too complecated for you to understand why and when.
It would be great to have this as configurable option at least. We really miss it in our company.

[loucurapt]

If I understood correctly, if someone else is invited to a "direct message", that someone will be able to see the entire history of that "room" by default.
The default setting for "who can see the room history" is "Members only (since the point in time of selecting this option)".

That seems very wrong to me!
At the very least that setting should default to "Members only (since they were invited)" for direct messages, and should not be changeable.
(And the server/protocol allowing this also seems wrong to me.)

I think "direct messages" should be even more private/secure than private rooms.

[jxu]

Direct chat (under "People" tag) should not allow others to be invited. This defeats the purpose of a direct chat.

[xvsun]

We are currently testing the solution from the BWI called Bundesmessenger. They implemented a way so there is no invite button in DM in the webclient. Is this just a workaround hack or something that should be considered in Element? https://gitlab.opencode.de/bwi/bundesmessenger/clients/bundesmessenger-web