[Story] Differentiate between room previews depending on join rules #2586
Comments
mxandreas
changed the title
mxandreas
changed the title
mxandreas
changed the title
|
@gaelledel We need a few designs for this story - have look at the "Other" task list in the issue for details. |
|
You can find all room previews in Figma for EX. Web will follow https://www.figma.com/design/7TqjqdMBaPpm3IavKsMYu6/Ask-to-join-(Knocking)?node-id=4766-43955&t=g2HrRvguv9eR0eDz-4 |
|
Can i also suggest a room not being joinable due to the room version not being supported by the server? (some room versions also require client support but that's probably rarer) Checking if the room version supports knocking might also be a good idea, but i don't know if that's something that will happen often Optimistic knocking might also be worth adding? I think nheko and element web does that, although it does seem harder to get right |
mxandreas
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Background
In order knocking to work, the join rules of the room need to be accessible to a user that is not yet member of the room. This was a challenge because even for rooms which were published in the room directory (and thus the information was available in principle), there was no proper API for getting the info & join rules by room alias or ID (the publicRooms API was not designed for that purpose). This led to getting MSC3266 into production (provides the necessary roomSummary API) and thus also revisiting the different scenarios the user may encounter.
For the context, the diagram below depicts all the different scenarios and room previews.
The overall goal is to minimize the chance that the user is presented with misleading information or actions when they get a link to a room or find it in the room directory.
Scope
In the scope of this story, there are 3 previews in which either the join rules are not known and/or the user may not be be able to join the room:
invite. This means that the user can not join the room without an invite. The user are shown the room information, but are informed that they need an invite; and there is no button to join.restricted. This means that the user is able to join only if they are member of a space (that is authorized for joining this room). However, the latter this is not straightforward to be checked in advance - thus user is shown the room information and a join button but they are warned that joining requires membership of a space, thus might fail.In the case of RP-07 and RP-08, joining is expected to fail. In that case the user is expected to receive a meaningful non-technical message about that. The same non-technical message can be used whenever the joining the room is logically denied (e.g. it does not fail because of a technical/network errors but the user does not have the right to join the room).
Designs:
Acceptance criteria
Size estimate
None
Dependencies
Out of scope
Open questions
Questions
Subtasks
Android
iOS
Rust
Other
The text was updated successfully, but these errors were encountered: