[Story] Create a new room (with ask to join & redesign)

[mxandreas]

Description

Background In order to fit in the option to create a room with the knock join rule, the design of the room creation modal has been revisited to ensure it is optimized for the most common use cases (not to overwhelm users with a lot of choices to think about), and the UX becomes also more consistent between EX and EW.

The main differences that will remain between EX and EW:

• EW continues to allow the creation of a room in the context of a space, hence it will allow a (private) room to be created with the accessible to space members aka restricted join rule.
• EW keeps the Block anyone not part of element.io from ever joining this room. toggle in the Advanced section.

The following 2 tables show how the user controls are mapped to the room configuration, note it does not include obvious 1:1 mappings (e.g. room name or topic).

EX:

EW:

It is worth explicitly noting that on EW the E2EE is no longer shown - it defaults to either OFF or ON, depending on room's visibility.

Conditions

• When the user is switching between the Private and Public visibility, the subsequent choices are reset to default.
  • E.g. effectively, when user selects Public as visibility, Anyone is always selected as access; and room address is auto-filled (from scratch) using current room name.

Public room & addresses

• Alias (in APIs and technical specifications) is a synonym to address (used on UI).
• To control if the room appears in the directory when browsing (e.g. the property Visibility in room directory in the tables above):
  • during room creation, the visibility property of the room creation API can be used;
  • after creation visibility can be changed using this API.
• A (technical) pre-requisite for the above is that the room has at least one alias:
  • during room creation, the room_alias_name of room creation API can be used;
  • for managing aliases later, there are 2 steps with following APIs:
  • create an (local to homeserver) alias with this API, e.g. PUT https://beta.ems.host/_matrix/client/v3/directory/room/%23laagri-b%3Abeta.matrix.org
  • publish the alias through the m.room.canonical_alias state event, e.g. PUT https://beta.ems.host/_matrix/client/v3/rooms/!vQBVkoHQCPajfjlWBi%3Abeta.matrix.org/state/m.room.canonical_alias/ {"alt_aliases":[],"alias":"#laagri-b:beta.matrix.org"}

Designs:

• Public room: iOS | Android | Web
• Private room: iOS | Android | Web
• Private room (in the context of a space): Web

Acceptance criteria

• The configuration of the created room follows the mapping above.
• When creating a room in the context of a space on EW, the Private visibility is selected by default and the Accessible to space members is selected by default (to keep current behavior).

Size estimate

None

Dependencies

• None

Out of scope

• There is a separate story for auto-filling the room address.

Open questions

### Questions
- [ ] Confirm that EW respect this well-known configuration to enforce E2EE to OFF (always)? If yes, we should keep that logic when creating the room and also apply it in EX. https://web-docs.element.dev/Element Web/e2ee.html#disabling-encryption-by-default

Subtasks

### Android
- [ ] https://github.com/element-hq/element-x-android/issues/3689

### iOS
- [ ] https://github.com/element-hq/element-x-ios/issues/3419

### Rust
- [ ] https://github.com/matrix-org/matrix-rust-sdk/pull/4145
- [ ] https://github.com/matrix-org/matrix-rust-sdk/pull/4151

### Other

[jmartinesp]

I've added a couple of PRs that changed the room creation stage in Rust so we can:

• Add a custom join rule (knocking).
• Set a canonical room alias.

Besides that, the existing API already allows you to customise visibility, the preset used for creating the room, and whether E2EE is enabled. I'm not sure if we're missing anything else.

[mxandreas]

As a result of the discussion with @gaelledel and @ganfra we have decided to change the permissions for invite and kick from admin to moderator when you create a Ask to join room. That means that the only effective difference compared to what we have right now, is that for invite you need to be a moderator. For kick, you already needed to be a moderator.

[mxandreas]

Made the following update:

Conditions

• When the user is switching between the Private and Public visibility, the subsequent choices are reset to default.
  • E.g. effectively, when user selects Public as visibility, Anyone is always selected as access; and room address is auto-filled (from scratch) using current room name.

[mxandreas]

This is to confirm the technical side of room publishing, and the address/alias that is required for that. I am pointing this out because this was not implemented in EX before and the topic is not trivial.

• The visibility / publishing of the room in the homeserver's public room directory is done with this API
• The room address/alias (which is a pre-requisite for the above) must be both:
  • A "local address" which is managed with this API
  • A "published address" which is a accomplished with the m.room.canonical_alias room event.

cc @ganfra