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

FTUE: history visibility settings lie in E2E rooms #13349

Closed
ara4n opened this issue Apr 23, 2020 · 11 comments
Closed

FTUE: history visibility settings lie in E2E rooms #13349

ara4n opened this issue Apr 23, 2020 · 11 comments
Labels

Comments

@ara4n
Copy link
Member

ara4n commented Apr 23, 2020

given we can't see history from before you join an E2E room, the history visibility settings should not claim that you can.

@valkum
Copy link

valkum commented Jul 9, 2020

Just hit this with a room on our homeserver. It seems RiotX handles this differently, as it shows the encrypted events before the invite (without a way to request keys from the senders (would that be even possible?)). Riot-web and desktop just don't show anything. Even non-encrypted previous events (before e2e was activated) are hidden.
May I suggest to show at least some form of banner (like the encryption activated banner in riotX) that informs the user about this fact? Could be a short term solution before much time flies by for reworking the history wording or something else.

@t3chguy
Copy link
Member

t3chguy commented Jul 11, 2020

Even non-encrypted previous events (before e2e was activated) are hidden.

it has no way of knowing they exist, if riot-web/desktop see undecryptable events from before your join then they hide them for a better first time user experience

@jryans
Copy link
Collaborator

jryans commented Aug 20, 2020

can't see history from before you join an E2E room

To be a bit more precise (and to verify my own understanding), history starts at the point you were invited, not joined, right?

@t3chguy
Copy link
Member

t3chguy commented Aug 20, 2020

Yes, my bad, assuming the right join rules;

@t3chguy t3chguy added the X-Needs-Product More input needed from the Product team label Sep 14, 2020
@t3chguy
Copy link
Member

t3chguy commented Sep 14, 2020

Unclear what we want done here, blindly hiding those settings seems wrong. Probably needs better copy for e2ee rooms?

@JonathanReifer
Copy link

+1 on this issue, right now "Members only (since the point in time of selecting this option)" seems to actually work like "Members only (since they were invited)" in e2ee rooms. At the very least, I'd grey-out that option for e2ee rooms, but it would be fantastic if that was actually an functional option.

@jryans
Copy link
Collaborator

jryans commented Dec 16, 2020

In the duplicate issue #14889, @lampholder said:

When you join an encrypted room you don't see the message history.
This makes sense, because a bunch of UISIs you can never fix is a nice thing to avoid.

However, it is suprising because:

  • the room settings still say you should have access to old messages
  • joining the room, you have no signal as to whether you're landing in a brand new room or one in which discussion is already in flight

This last point is probably more important - I find landing in such a room I don't know quite how to behave.

@avalenn
Copy link

avalenn commented Apr 2, 2021

This is even more confusing when you leave the room and then rejoin it.
On element-android I can see the old messages (excepting those posted when I was not in the room which are rightfully marked as impossible to decrypt).
On element-web my history is completely truncated at my last join, even if I would be able to decrypt some of the older messages.

@jryans
Copy link
Collaborator

jryans commented Apr 20, 2021

We have now enabled key sharing on invite, so I believe the visibility settings now make sense for E2EE rooms.

@jryans jryans closed this as completed Apr 20, 2021
@aaronraimist
Copy link
Collaborator

@jryans the "Anyone" option still exists for E2E rooms which is a lie

@SimonBrandner
Copy link
Contributor

Maybe a new issue for that specifically might be better?

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

No branches or pull requests

8 participants