You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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"}
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
The content you are editing has changed. Please copy your edits and refresh the page.
mxandreas
changed the title
[Story] [WIP] Create a new room (with ask to join & redesign)
[Story] Create a new room (with ask to join & redesign)
Oct 16, 2024
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.
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.
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.
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:
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:
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
Public room & addresses
visibility
property of the room creation API can be used;room_alias_name
of room creation API can be used;PUT https://beta.ems.host/_matrix/client/v3/directory/room/%23laagri-b%3Abeta.matrix.org
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:
Acceptance criteria
Size estimate
None
Dependencies
Out of scope
Open questions
Questions
Subtasks
Android
iOS
Rust
CreateRoomParameters::join_rule_override
matrix-org/matrix-rust-sdk#4145canonical_alias
field toCreateRoomParameters
matrix-org/matrix-rust-sdk#4151Other
The text was updated successfully, but these errors were encountered: