Disable invites for 1:1 private DMs/direct chats by default OR ask for 2nd user's consent before actually inviting

[opusforlife2]

Suggestion

Please read element-hq/element-meta#320 for context.

I would like for all clients/servers to disallow inviting a 3rd user into a private 1:1 chat by default.

If a user wants advanced functionality by inviting bots or personal assistants, that should involve an extra step or two, not the other way around, as the workaround suggested in the linked issue does.

The most straightforward method of creating and using a 1:1 chat, without tweaking anything, should cater to the average non-tech-savvy user, someone who would have no idea of the consequences of being part of a 1:1 chat where both users are admins and can invite all and sundry to become part of a potentially private conversation.

This could be a very targeted, narrow component of #289.

Alternative

I would like for all clients/servers to ask the 2nd user for consent before sending out an invite to any 3rd user to a private 1:1 chat. This will ensure that no single user can abuse their admin privilege to allow others to gatecrash a private conversation.

[Half-Shot]

As per matrix-org/synapse#10000 (comment), I'm closing this. Please keep the conversation limited to element-web until a conclusion has been reached.

[t3chguy]

The issue really does not belong only in Element Web, its about the application of DMs across the protocol, not about the path that Element specifically takes.

[Half-Shot]

Okay, I don't think we need three issues to track this bug though. We can keep this one open instead though.

[ShadowJonathan]

Please don't make an issue on matrix-org/synapse, expecting the synapse team to immediately cede to your request, prioritisation exists.

While this may be an important issue for you, to me it looks like this requires some heavy-handed changes to the spec to disallow such invitations, though right now this is not requested or even desired behaviour due to account migrations, where someone might invite and op a new account to a DM, and have their old account leave, Element themselves (Element Home) uses this approach.

Until Decentralized Accounts exist (matrix-org/matrix-spec-proposals#2787), I don't see this latter part changing, and maybe it'll be possible to fold this behaviour into Canonical DMs (matrix-org/matrix-spec-proposals#2199), where it can be part of the whole "DM" mode of communication.

[opusforlife2]

You guys are the maintainers with experience on which repo the issue belongs in, so closing the other 2 issues is fine by me.

expecting the synapse team to immediately cede to your request

There was no expectation of that, the only expectation I had was that someone would think "yeah, it seems like a serious problem, lets prioritise this issue". If you decide this should go through the standard MSC process, that is fine.

[opusforlife2]

where someone might invite and op a new account to a DM, and have their old account leave, Element themselves (Element Home) uses this approach.

This is also advanced functionality, only needed by tech experts or power users at the maximum, and I'm all for such facilities existing, but not by default. That way lies madness.

A great example is Firefox. You can tweak about:config to your heart's extent to get your desired behaviour out of it, but the browser comes with sane defaults and doesn't expose users to gory details or expert level behaviour until they explicitly opt into it.

[t3chguy]

This is also advanced functionality, only needed by tech experts or power users at the maximum

No it isn't

Element Home (https://element.io/blog/element-home/) wraps it up as part of a really simple flow,
but if your rooms are set up in the way you describe then they will be entirely lost in the migration

[opusforlife2]

I'm not saying average users shouldn't be able to migrate to Element Home.

What I mean is, you, as a coder, can implement this however you like, but the functionality doesn't need to be exposed to the average user.

Most of the issue is about visibility of advanced options.

[t3chguy]

Given federation/decentralisation it pretty much is limited to being implemented as inviting the user identity you are migrating to and leaving from the old identity, given this proposal disables that ability, it'll break the migration of DMs

[opusforlife2]

Okay, now I get it. Yeah, Canonical/Immutable DMs should already have been implemented before Element Home migration was created. Then it would have taken a different route.

[KitsuneRal]

I guess the best way forward would be to enable "consensual invitations" when in order to generate an invite all co-admins have to agree on doing it. Just denying/forfeiting the right to invite strikes away too many good use cases.

[SimonBrandner]

I guess the best way forward would be to enable "consensual invitations" when in order to generate an invite all co-admins have to agree on doing it. Just denying/forfeiting the right to invite strikes away too many good use cases.

That would still make stuff like account migration harder...

[t3chguy]

Yeah, what if your friend passed away and you didn't want to lose the history for sentimental reasons yet now they can never consent to your action

[opusforlife2]

Yeah, what if your friend passed away and you didn't want to lose the history for sentimental reasons yet now they can never consent to your action

Bit weird to be held hostage by a chat history, no?

Anyway, a solution has magically appeared: https://matrix.org/blog/2021/05/20/google-summer-of-code-2021#jaiwanth-exporting-conversations-from-element.

Not only should conversations be exportable, they should be importable into Element as well. (And maybe other clients eventually.)

Edit: For an ecosystem as vast and diverse as Matrix, Export/Import of chats/spaces/accounts should be a first class citizen, anyway.

[SimonBrandner]

they should be importable into Element as well.

That is not planned for GSOC though, iirc.

This also doesn't solve the migration problem... To make this work you'd need to completely rewrite the script and you'd also need an MSC for a common export/import format...

[opusforlife2]

That is not planned for GSOC though, iirc.

That was my own suggestion. I'm aware it's not part of GSOC.

you'd also need an MSC for a common export/import format...

That's exactly what I'm suggesting. First-class citizen.

[opusforlife2]

Okay, I was ruminating on this problem for a while. Here is a proposal:

Spaces(TM). The new graphene. What if every "chat" in the chat list was implemented as a Space with a directory structure? Then it could contain multiple Rooms which cater to specific things, allowing for more granularity in multiple ways. This structure may or may not be exposed to the user.

Option 1 - Space with directory structure exposed to user:

• 1:1 Chat with UserX:
  • DM Room (Main, immutable/canonical) : No Invites/Bots/Assistants of any kind.
    • "Inviting" a 3rd user automatically creates a new Group Chat (this could be explained by a dialogue box?).
  • Bot Room (Optional/addable) : You can send messages here to interact with Bots, and they can't see other Rooms.
    • Alternatively, all messages a Bot is supposed to see should automatically be added to this Room instead of the DM Room.
    • Mirrors of the message in both Rooms (implemented as Replies, maybe?). Tapping on the Reply part in the DM Room takes you to the corresponding message in the Bot Room, and vice versa.
  • Assistant Room (Optional/addable) : Same deal as Bot Room. (I don't know what they are and how they differ from Bots.)
  • Media/File Room (Automatically added when needed) : This would only contain media/file messages.
    • Mirrors in both Rooms. Same concept as above.
  • Groups (Automatically added when needed) : An expandable item which exposes a list of all groups you share with UserX.
  • Spaces (Automatically added when needed) : Same as Groups.
• Group Chat with UserX + UserY: everything corresponds to 1:1 chat, but with some difference.
  • Chat Room (Main) : No Bots/Assistants of any kind. Invites are allowed (but can be disabled?).
    • When being created, maybe the client should ask whether you want to be the only Admin (behaviour users will be used to from other apps) or every added member should also be an Admin.

Option 2: Space with directory structure hidden from user:

• 1:1 Chat with UserX:
  • DM Room: Same as before.
  • Bot Room: Hidden from UI. Maybe there can be an option to unhide it (for debugging purposes?).
  • Same with other Rooms. Hidden from UI, but functionality remains the same.
• Group Chat with UserX + UserY:
  • Chat Room: Same as before.
  • Bot Room: Hidden from UI, etc.

Not only will this directory structure help in keeping things separate, it will also make implementing Export/Import functionality easier. Everything will already be neatly bundled into separate Rooms.

Further, once Export/Import is implemented, that could then become the default way of migrating users on Element Home.

[opusforlife2]

No feedback on this?

[PeerD]

I created #587 some time ago to tackle the same problem but with a different solution. You can still invite more people/bots etc. but they can by default not see the entire history.

[opusforlife2]

@PeerD Thank you, but that solution breaks Element Home migration functionality: element-hq/element-meta#320

[eras]

Isn't the correct solution to this to use a social mechanism? Basically, if your DM peer invites an additional bot to the discussion, you are free to leave the room.

In this case the bot may be able to access historical messages from the room. This does not fundamentally change by making it impossible to invite a bot to the room: a participant of a room can retrieve the messages anyway and pass them to whomever regardless of Matrix permissions. In addition, the participant can have additional programs (bots) using the same account.

Depending on your client configuration, a bot from a separate account would be unable to decrypt messages the client has said, unless the client verifies the bot—this though is not the default configuration of Element.

Having those Matrix server permission limitations would actually cause practical problems outlines in other messages in this issue.

As a personal anecdote I have invited backup accounts (running on other homeservers) to DMs to allow me access should my primary HS have issues.

Should I need to have to ask a permission from someone else to do this? In my opinion, no. It is completely in my own hands whom I give my communication or communication I have access to, similarly as it is your in your control to decide whom you give your communication. By trusting your communication with me you are by extension trusting what I may be able to do with such communication afterwards, which includes passing it to secondary accounts, to bots, print it out and send to a newspaper; simply after the message has sent by the peer, it is out of the hands of the originator what is done with the message, and the only recourse is to stop communicating further.

(The ability to limit bot communication visibility is in my opinion unrelated to DMs and can be useful in rooms of any size, DM or not.)

[opusforlife2]

@eras I get your point, that what a user can theoretically do with the chat history won't be prevented by this change.

However, my social circle isn't made up of leet hackers (or 1337 haxx0rs, as they say), and I feel quite confident in saying that would be the case for the vast majority of people. I'm assuming Matrix is intended to be used by everyone, and not just the technologically inclined?

Most of the people I peddle the app to are average users who don't have the time or inclination to delve into the intricacies of this app or most others. My biggest worry with this (faulty) default is not a tech-savvy malicious user deliberately misusing it to cause harm (though making it easy for less savvy malicious people to cause harm, just to preserve the status quo, seems weird). I am worried about people who aren't tech-savvy accidentally polluting their (and my) chat histories by inviting one or more accounts to our 1:1 chat. This is why I'm asking for a chat where only 2 accounts can exist, a true 1:1 chat, or an Immutable DM, as per existing Matrix jargon. 2nd user's consent is the next best option.

By the way, even for Group DMs, the history should be visible only from the point an account was invited.

I thought this basic principle was universal in software design: you set the defaults to best cater to the average user. Any user who needs advanced functionality can then be provided the option to change the configuration to suit their needs.

---

P.S.: This problem is further exacerbated by the fact that the UI and messaging regarding DMs vs Rooms is unclear, as I mention in element-hq/element-android#3409.

[elderkeltir]

Not having DM in 2021 is kinda strange 🤔

[opusforlife2]

I just came to know that this problem was partially mitigated by the lack of MSC3061. But that will change after it is merged, and we'll be back at square one.