[Story] Change room settings (with ask to join & redesign)

[mxandreas]

Description

Background

Similarly to the room creation, the room settings have been revisited, to support the knock join rule in there. The starting point for EW and EX is different - EX currently supports just editing the name, topic and avatar of the room while EW already had the option to change join rules, E2EE, add/edit room addresses, etc. The goal is to make EW and EX is consistent, and only have differences when there is a clear reason for that.

Known differences between EX & EW:

• EX will not support changing room join rule to restriced (Space members), since it generally yet does not support Spaces.
• EX will only support adding/editing only a single room address since typically multiple addresses are not frequently used. EW keeps this functionality to make sure there are still means to do it.

Controls & Conditions

The room name, topic and avatar parts keep working as before.

Room access

• This controls the room’s join rules:
  • Invite only => invite
  • Space members => restricted
  • Ask to join => knock (or knock_restricted - see details below)
  • Anyone => public
• The option Space members is disabled on EX, and only shown if the current room access is restricted. User can see that this is the current room access (e.g. room was created by EW), and select another option, but never re/select this option.
• When a room with knock_restricted is opened, the option Ask to join is selected.
  • The value knock_restricted is retained as long as user has Ask to join selected before saving changes.

(Main) Room address

Under the hood, Matrix has a number of ways declaring the alias(es) for a room:

• The room event m.room.canonical_alias can contain one "main" alias (field alias) and a list of alternative aliases (field alt_aliases). These are also referred to as "published aliases" as they are federated across homeservers.
• Each homeserver can also maintain a list of aliases for a room which are managed by this directory-room-alias API. These are also referred to as "local aliases" as they are not federated.

We want to keep it as simple as possible for the end user - e.g. not to drag them into the details of the published vs. local addresses as well as only keep it to one alias on EX, since multiple ones are rarely needed. However, note that due to federation, the room may actually still have multiple ones (e.g. for the different homeserver/users).

The "algorithm" to determine what is shown as room address and what is done when it is changed is as follows. Assuming the logged in user is @admin:example.com,
the address to be shown is determined by one of the following (whichever matches first is used):

1. canonical_alias.alias if it matches *.example.com
2. Any of canonical_alias.alt_aliases that matches *.example.com
3. canonical_alias.alias
4. canonical_alise.alt_aliases

When adding an address #new:example.com or changing it from #old:.com to #new:example.com:

• If there is no canonical_alias.alias or it matches *.example.com then replace it with #new:example.com.
  • Else if canonical_alias.alt_aliases contains exactly one that matches *.example.com, then replace it with #new:example.com
  • Else add #new:example.com to the list of canonical_alias.alt_aliases
• If == example.com && there is an existing local/HS alias #old:.com then delete it.
• Add a new local/HS alias #new:example.com.

Additionally:

• Only shown room address field when the join rule is knock or public.
• When join rules are changed (to something other than knock or public), the main address or alternative addresses are kept, e.g. if something already exists, it is not removed.
• If there is no address yet, autofill it from the room name.
• Needs to be validated for invalid symbols, and checked if it is available using the same logic as when creating a room.

Visible in public room directory

• This toggle controls if the room can be found in the directory of the homeserver of the currently logged in user, and is controlled by this API.
• Only shown when join rules are knock or public.
  • When a user changes join rules to something other than knock or public, the room should be automatically made invisible (private) in the room directory.

Enable end-to-end encryption

• This toggle controls if the room has E2EE turned ON (with m.room.encryption event).
• This cannot be turned OFF after it has been turned ON.
• The user has full control over when to turn this ON (e.g. we do not set any constraints), however a disclaimer is shown with things to consider when trying to turn it ON.

Who can read history

• This controls the history visibility of the room (with m.room.history_visibility event):
  • Anyone => world_reabable (shown when: (join rule is public and E2EE is OFF) or when current value is world_readable)
  • Members since selecting this option => shared
  • Members since they were invited => invited (shown when: join rule is NOT public or E2EE is ON or current value is invited or current value is joined)
• If the current value is joined, still the option Members since they were invited is selected.
  • The value joined is in this case also retained as long as the user has this option selected before saving.
• When the user changes the join rules and/or E2EE so that a previously selected option disappears, we automatically select the safest option:
  • When the world_reable option disappears, invited is selected.
  • When invited disappears, shared is selected (this actually can not happen as long as there is no option to turn E2EE OFF).

Permissions

• Only need to update the copy/labels to indicate that accept requests to join is the same permission as inviting users, and declining requests to join is the same permission as kicking people.

Designs

• Invite only: iOS | Android | Web
• Anyone / (main) address exist: iOS | Android | Web
• No (main) address yet: iOS | Android | Web
• Turning on E2EE: iOS | Android | Web
• History visibility: iOS | Android | Web
• Permissions: iOS | Android | Web

Acceptance criteria

• TBD

Size estimate

None

Dependencies

• None

Out of scope

• Nothing

Open questions

Questions

Preview Give feedback

1. If you open a room with a restricted or knock_restricted join rule on EX, what should we show in the room access?
2. If you open a room with the knock_restricted join rule on EW, should Space members or Ask to join be selected?
3. If you open a room with history visibility joined on EW or EX, what should be shown?

Subtasks

Android

Preview Give feedback

No tasks being tracked yet.

iOS

Preview Give feedback

No tasks being tracked yet.

Rust

Preview Give feedback

No tasks being tracked yet.

Other

Preview Give feedback

No tasks being tracked yet.

[gaelledel]

@mxandreas

Questions sections:

• If you open a room with a restricted or knock_restricted join rule on EX, what should we show in the room access?

---> Ask to join is selected in the room settings

• If you open a room with the knock_restricted join rule on EW, should Space members or Ask to join be selected?
  ---> i'd assume the best choice is Ask to join selected

• If you open a room with history visibility joined on EW or EX, what should be shown?
  ---> Unsure what you mean

[mxandreas]

If you open a room with a restricted or knock_restricted join rule on EX, what should we show in the room access?
---> Ask to join is selected in the room settings

For knock_restricted that works (because you can knock). For just restricted it would be misleading because no knocking is available - also, this is a case we need to be more worried about, because this is what EW is using. Some options:

• Do not select any radio button.
• Add a radio button "Space members" that is always disabled (with some disclaimer that this is not yet supported on EX).

If you open a room with the knock_restricted join rule on EW, should Space members or Ask to join be selected?
---> i'd assume the best choice is Ask to join selected

I thought "Space members" is better because then you can select/change the spaces which you might want to do (which reminded me that we may have missed the selection of spaces in the designs). Ask to join does not not have any additional configuration attached to it.

If you open a room with history visibility joined on EW or EX, what should be shown?
---> Unsure what you mean

We do not have a radio button for the history visibility joined, because there is no good use case for it in the context of messaging. As this is really an edge case (unlikely that other clients use it), I suggest we just do not select any of the radio buttons here.

[Velin92]

If you open a room with a restricted or knock_restricted join rule on EX, what should we show in the room access?
---> Ask to join is selected in the room settings

For knock_restricted that works (because you can knock). For just restricted it would be misleading because no knocking is available - also, this is a case we need to be more worried about, because this is what EW is using. Some options:

• Do not select any radio button.
• Add a radio button "Space members" that is always disabled (with some disclaimer that this is not yet supported on EX).

If you open a room with the knock_restricted join rule on EW, should Space members or Ask to join be selected?
---> i'd assume the best choice is Ask to join selected

I thought "Space members" is better because then you can select/change the spaces which you might want to do (which reminded me that we may have missed the selection of spaces in the designs). Ask to join does not not have any additional configuration attached to it.

If you open a room with history visibility joined on EW or EX, what should be shown?
---> Unsure what you mean

We do not have a radio button for the history visibility joined, because there is no good use case for it in the context of messaging. As this is really an edge case (unlikely that other clients use it), I suggest we just do not select any of the radio buttons here.

Couldn't we just treat the joined case just as the invited one? They don't make much difference, not at least one that would be noticed by most users, so essentially if a room that is in a joined state gets edited we just display the "Since invited" option.

Also I have another question, when E2EE is enabled, I imagine we want to completely avoid displaying in any case the "Anyone" history visibility option (even if for some reason the user has set the room to public). So in case a public visibility is selected and E2EE is selected, I imagine the only possible (and selected option) for the history radio, would be "Since selecting this option" one.
Correct?

[mxandreas]

Couldn't we just treat the joined case just as the invited one? They don't make much difference, not at least one that would be noticed by most users, so essentially if a room that is in a joined state gets edited we just display the "Since invited" option.

This is fine with me. When user saves settings, we should keep joined (unless user selects another value). Not that it matters too much (as it is an edge case) but just to agree on what is expected.

Also I have another question, when E2EE is enabled, I imagine we want to completely avoid displaying in any case the "Anyone" history visibility option (even if for some reason the user has set the room to public). So in case a public visibility is selected and E2EE is selected, I imagine the only possible (and selected option) for the history radio, would be "Since selecting this option" one.
Correct?

Yes, it is correct that if E2EE is ON, then the "Anyone" history visibility is not shown (as reading the messages is not possible anyway).

However, when E2EE is ON, then the "Invited" history visibility is still shown (according to the current logic in the story) - because to hide it, E2EE needs to be OFF && join rule == public. Thus, the "Since selecting this option" would not be the only option.

[mxandreas]

We synced during the meeting and concluded as follows:

1. For the knock_restricted join rule, both EW and EX select Ask to join (to be consistent).
   1.1 The value knock_restricted is retained as long as user has Ask to join selected before saving (e.g. is not changed to knock).
2. For the restricted join rule, EX selects Space members which is always disabled.
   2.1 The user can select another option, but not never re-select Space members.
3. For the joined history visibility, both EW and EX select Members since they were invited.
   3.1 This is not technically correct, however the joined is a rather big edge cases for messaging clients, thus not worth of adding options/complexity that are unlikely to be ever used.
   3.2 The value joined is retained as long as user has Members since they were invited selected before saving (e.g. is not changed to invited).

The story will be updated accordingly.