Immutable DMs / private rooms / public rooms

[ara4n]

Tracking bug for reconsidering whether we should let rooms arbitrarily change 'flavour' between 1:1, private group chat and public chatrooms. The main reason for considering preventing this is to simplify the UX of clients - however, the restriction would have to be imposed at the Matrix level to prevent inconsistent/unexpected behaviour throughout the network. https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-barbecues/ contains more of the backstory.

We already have some old bugs discussing this which I need to track down and add here.

[ara4n]

Stuff to consider:

• This would only be tenable if we had a way to copy/clone/shallow-copy history from existing rooms into a new room, so you could still 'invite a user into a DM' by sharing however much of the DM was relevant to them.
• We'd probably need to specialcase bots so they /can/ be invited into DMs (but are clearly a second class citizen).

[turt2live]

Special casing bots would also probably help with https://github.com/vector-im/riot-web/issues/3087

See also: https://github.com/matrix-org/matrix-doc/issues/1206

[florianjacob]

While I think the idea to differentiate between a banquet and a barbecue is great and will help, I don't yet understand how that would benefit from immutable room flavour when compared to some new kind of tagging mechanism, like for 1:1 rooms, which would determine whether the room should be considered a banquet or a barbecue. 🤔 Especially when this would sacrificing the simplicity of the "at the core, everything is just a room and all rooms can do the same" mental model, and gives us history duplicates on search and special-casing for bots and other invite interactions in return. /me peeks at my XMPP client

So e.g. if someone is invited to a DM, starting a barbecue, what exactly should happen?

1. is the intention that I end up with two rooms, the DM and a barbecue, that will share room history on creation, or at least a significant part of it, but then deviate and branch off in two directions when users continue writing in the rooms? Tagging won't be sufficient in that case, but isn't that quite a confusing UX as well?
2. Will the old DM room vanish? Then retagging, moving the room from one client to another, seems to be the easier option.
3. Will the old DM room be an immutable archive to show in the DM view, with a link or something at the bottom leading to the new barbecue room? Then that archive could be limited to the point where the room tag was changed, no need for a second room with copied history.

[ara4n]

See also https://github.com/vector-im/riot-web/issues/7315