-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
We surely need a way to clear/ACL scrollback for a room with various different semantics (SPEC-134) #32
Comments
Jira watchers: @dbkr @erikjohnston @ara4n |
Links exported from Jira: relates to SPEC-17 |
We also need some kind of way to define whether scrollback should be hidden for new participants or not. -- @ara4n |
We've repeatedly had folks asking for a way to optionally stop past history from being visible when you join a room. Use cases include:
This is easy in an E2E world, as you simply re-key the room to demarcate a point that new users will not be able to decrypt beyond. For non-E2E, we need equivalent behaviour which should be compatible with the UX of the E2E scenario. My proposal is to have a new timeline event: m.room.rekey or m.room.hide_earlier_history or similar. Any client with sufficient permissions can PUT this into the room - and it acts as a line in the sand beyond which no new users in a room are allowed to read scrollback. We can also use it as the API in E2E used to trigger a rekey. -- @ara4n |
I don't think either of these proposals cover the 2nd use case (sharing partial history with an new person invited to a chat) since you'd only be able to hide history previous to when you sent that event, which would be all history so far, meaning the new person wouldn't see any history at all. Have I misunderstood? -- @dbkr |
This probably should talk pruning and also archiving (# months to keep data before archiving to offline logs) and archive retention period (# of months to forever). Just because something is pruned (by a user or admin) doesn't mean that it shouldn't also be archived. Thinking here that pruning only refers to viewing of the messages, not the actual storage of them (inferred from m.room.hide_earlier_history reference). It is important for industries that are regulated (government, healthcare, banking) and must report on things or if legally obliged to turn over history for X amount of time for Y user (and any interactions with Y user). It's also important that after the retention period that information is stricken from the archives. Some rough ideas: System Defaults:
Room Overrides
-- Michael Picher |
The above comment probably has more relevance to https://github.com/matrix-org/matrix-doc/issues/447.... One particular room scenaio I'm concerned with is that of a typical real-world meeting room. Here's the scenario:
Meeting 1: Meeting 2: Meeting 3:
Meeting 4:
Meeting 5:
In non-persistent communications this is easy, it's like an audio or video conference bridge in that you hear / see what you hear & see while you're in there. Each connection to the room is a new experience for the user (there's no history) from that point in time until they leave. -- Michael Picher |
As requested by Erik, moving the "how to ACL history" discussion from spec-17 to here. I suggest we keep this bug for tracking ACLs, and move any pruning content from HS discussion to https://github.com/matrix-org/matrix-doc/issues/447. To quote from spec-17:
-- @ara4n |
From a protocol implementation perspective, some thoughts are:
So, an implementation of "people can't see events before they joined" would only require a special state to be set at the time. The bug/feature with this is that if that state is set after a server has joined, they could continue to backfill past when they joined, since the special state only applies after it is set. The upside: there is little risk of races. Downside: surprising behaviour? |
From a UX perspective, I think all we need for now is a room setting to prevent history from being visible to new users. Ideally this would be applicable on per-user granularity, but it would be fine to start off as a global setting. The only UX subtlety is what happens when you turn history visibility back on - I suggest that we only make visible the history which occurs /after/ the setting is reenabled. This avoids leaking stuff which folks thought was effectively off the record to non-members in the room. Whilst the fullblown multiDAG idea is interesting I'm hoping we can avoid rewriting federation to support this. Erik: I don't follow your suggestion in the comment above. -- @ara4n |
bq. From a UX perspective, I think all we need for now is a room setting to prevent history from being visible to new users. Ideally this would be applicable on per-user granularity, but it would be fine to start off as a global setting. The only UX subtlety is what happens when you turn history visibility back on - I suggest that we only make visible the history which occurs /after/ the setting is reenabled. This avoids leaking stuff which folks thought was effectively off the record to non-members in the room. That should be a relatively simple and sane thing to implement. bq. Whilst the fullblown multiDAG idea is interesting I'm hoping we can avoid rewriting federation to support this. Agreed. bq. Erik: I don't follow your suggestion in the comment above. Basically it implements your suggestion :) |
Currently being implemented: matrix-org/synapse#196 |
The current implementation is problematic, as you can't historically set scrollback visibility. In practice it's rare to know at the time whether you want the current conversation to be visible or not to future people - it's something you typically decide afterwards at the point of (say) inviting others into the room. This sounds to be Hard because of federation consistency issues when you start trying to change the behaviour of past events in retrospect... but we need to work out a way to fix it somehow. -- @ara4n |
https://github.com/matrix-org/matrix-doc/issues/533 is the issue tracking retrospective history visibility. Mental note to create new issues to track all the other history-storage issues conflated together in this issue and close this one off. -- @ara4n |
I can think of many flavours of wanting to clear scrollback:
The only one we actually support currently is redacting events forever - but only by looping through redacting them one by one, which is horrific.
Any ideas?
(Imported from https://matrix.org/jira/browse/SPEC-134)
(Reported by @ara4n)
The text was updated successfully, but these errors were encountered: