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
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
robintown opened this issue
May 4, 2021
· 2 comments
Labels
A-Syncdefects related to /syncS-MinorBlocks non-critical functionality, workarounds exist.T-DefectBugs, crashes, hangs, security vulnerabilities, or other reported issues.
When a user joins a room with history visibility set to join or invite, they may find recent state events pertaining to the current state of the room included in the timeline that, according to the history visibility spec, should be hidden.
It is also of practical concern. For example, a user joining a recently created room with limited history visibility will see all of the state events from the room's creation, leading them to falsely believe that there must have been no messages sent between the room's creation and when they joined. For this purpose, it would also be nice if the m.room.create event would be hidden as well (as e.g. Dendrite does), however I'm not entirely sure that that's the correct thing to do (since history visibility is shared for the split second of the room's creation).
Optimally, there would be a way to solve matrix-org/matrix-ios-sdk#341 while also applying history visibility rules correctly.
Steps to reproduce
Create a room with history visibility set to invite or join
Possibly send some messages
Join the room as a different user
Some state events (name, topic, etc.) that come after the history visibility state event but before the second user was invited/joined will nevertheless be visible to them in the timeline.
Version information
Homeserver: townsendandsmith.ml
Version: 1.32.2
Install method: NixOS module
Platform: NixOS unstable
The text was updated successfully, but these errors were encountered:
I think the concrete suggestion here is that we shouldn't put state events in the timeline section of the sync?
erikjohnston
changed the title
Current state events visible contrary to history visibility rules
State events included in timeline section of sync when history visibility is set to join
May 13, 2021
erikjohnston
added
S-Minor
Blocks non-critical functionality, workarounds exist.
T-Defect
Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
labels
May 13, 2021
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
A-Syncdefects related to /syncS-MinorBlocks non-critical functionality, workarounds exist.T-DefectBugs, crashes, hangs, security vulnerabilities, or other reported issues.
Description
When a user joins a room with history visibility set to
join
orinvite
, they may find recent state events pertaining to the current state of the room included in the timeline that, according to the history visibility spec, should be hidden.I see that this behavior was introduced in #2451 as a workaround for matrix-org/matrix-ios-sdk#341 (and is in fact being tested for), however it is contrary to the spec as far as I can tell.
It is also of practical concern. For example, a user joining a recently created room with limited history visibility will see all of the state events from the room's creation, leading them to falsely believe that there must have been no messages sent between the room's creation and when they joined. For this purpose, it would also be nice if the
m.room.create
event would be hidden as well (as e.g. Dendrite does), however I'm not entirely sure that that's the correct thing to do (since history visibility isshared
for the split second of the room's creation).Optimally, there would be a way to solve matrix-org/matrix-ios-sdk#341 while also applying history visibility rules correctly.
Steps to reproduce
invite
orjoin
Some state events (name, topic, etc.) that come after the history visibility state event but before the second user was invited/joined will nevertheless be visible to them in the timeline.
Version information
The text was updated successfully, but these errors were encountered: