-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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 can run out of localstorage #3660
Comments
If using indexedDB I don't think we would run into storage limitations in any realistic scenario: https://developer.chrome.com/apps/offline_storage#temporary Though if such a thing were to occur (e.g. since maximum storage is % of Disk space restriction for most users this would be in the Gigabytes) I would suggest an option to export a file with all of the relevant keys (or maybe all session keys that are unused for X amount of time and the user can figure out where they want to store it). Btw even if a client prunes old keys, they can later re-request Inbound Megolm Session keys from other members present in the group chat (as long as one user still has a session key) or is there no specification for something like that? |
This would be element-hq/element-meta#647 |
Having just run out of localstorage myself, I thought I would do some quick sums to see what is filling it up.
In summary:
This is interesting, because there is no reason for us to have 7MB of device info there: for some reason we have the device info for everyone we've ever seen in any room, including unencrypted rooms. This may be related to #3588. It also presents a workaround for the problem, which is to delete all the device info. This will of course mean that we forget any details about verified devices, but that may be preferable to an unusable session:
|
I agree that there is no need to store Device Info in localStorage, indexedDB is a better place for this and as far as I am aware, matrix-js-sdk / riot-web are actually refreshing user-device lists on selecting the user-device pane anyways (although I suppose for message sending it doesn't refresh unless there is a new_device event, not sure if I am remembering correctly?) On a side-note for dealing with very large e2e rooms, the strategy could be, share first with 'recently active', next with 'online', next with 'offline' - for this to work well the client should be able to send the actual m.megolm encrypted message as soon as key sharing has been done with 'recently active'. (The UI for the later should delay showing an 'unable to decrypt message' and instead give as few minutes to wait for the incoming key-share). |
I think you're missing the point. IndexedDB might be a better place, but my surprise is not that we are storing device info in localstorage, but 7.7MB of it. Basically: #3588 means that we are filling up localstorage with device lists for users we don't care about. |
To increase the possibility that this issue gets found: I had the following error in my dev console
|
this should no longer be an issue (at least once riot-web is released), because @dbkr has moved things to indexeddb. |
because we try to store megolm keys forever, and then all hell breaks loose
The text was updated successfully, but these errors were encountered: