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.
I would like to be able to see on the click of a button, what servers are keeping which data classes about my login sessions.
The would mean I would see what sessions are there and then I can drill deeper into each session to see which servers are holding state about the session, and then going deeper, seeing for what rooms a server keeps my session data around, and what classes of data these are (e.g. user name, 3PIDs, login time, activity timestamps....). This data should be updated along with the regular operation so that it will not be a an additional burden on the servers when a user drills into that data.
This would be helping with GDPR compliancy and help users to better understand what data is kept around for which rooms they are using, providing decision material for opting out of certain rooms. This would be most helpful when room history becomes optional (as requested in another feature request), so then one can see what rooms need to be left to minize state data kept around on the own activity.
The text was updated successfully, but these errors were encountered:
This seems more spec level than Synapse level. It might be related to matrix-org/matrix-doc#1512 (or one of the linked issues in there), but I'm not 100% sure.
Description:
I would like to be able to see on the click of a button, what servers are keeping which data classes about my login sessions.
The would mean I would see what sessions are there and then I can drill deeper into each session to see which servers are holding state about the session, and then going deeper, seeing for what rooms a server keeps my session data around, and what classes of data these are (e.g. user name, 3PIDs, login time, activity timestamps....). This data should be updated along with the regular operation so that it will not be a an additional burden on the servers when a user drills into that data.
This would be helping with GDPR compliancy and help users to better understand what data is kept around for which rooms they are using, providing decision material for opting out of certain rooms. This would be most helpful when room history becomes optional (as requested in another feature request), so then one can see what rooms need to be left to minize state data kept around on the own activity.
The text was updated successfully, but these errors were encountered: