Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Story] Set the history visibility to invited when creating an E2EE room #2519

Open
6 tasks
mxandreas opened this issue Sep 4, 2024 · 1 comment
Open
6 tasks

Comments

@mxandreas
Copy link

mxandreas commented Sep 4, 2024

Description

Background

Currently, when a new room is created with EX, and the Private room option is selected, then:

  • E2EE encryption of the room is turned on.
  • History visibility (m.room.history_visibility) is set to shared (meaning that members who join are supposed to see messages that were sent before they were invited).

In practice, this combination is not supported yet - meaning that the messages before a user was invited are visible, but can not be decrypted. Thus, for sake of clarity, it is desired that when E2EE encryption is turned on, the history visibility defaults to invited instead of shared.

As a user creating a new E2EE room,
I want the history visibility of such room to be defaulted to invited
So that the members who join the room would not be confused why they can't read the content of the past messages.

Acceptance criteria

  • When a new room with E2EE is created, its history visibility defaults to invited.

Leads

  • Tech:
  • Design:

Size estimate

None

Dependencies

  • None

Out of scope

  • Nothing

Open questions

Questions

Preview Give feedback
No tasks being tracked yet.

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.

Sign-off

Android

  • Design sign-off on completion
  • QA sign-off on completion
  • Product sign-off on completion

iOS

  • Design sign-off on completion
  • QA sign-off on completion
  • Product sign-off on completion
@mxandreas
Copy link
Author

Leaving a note that it makes sense to tackle this as part of the Knocking project, as we touch this part of the app there anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant