Switch to persistent storage to avoid data loss

[jryans]

We can request "persistent storage" from the browser (navigator.storage.persist) so that it won't remove data when space is low.

Browsers decide whether to approve / deny differently:

• Chrome: Approved only if your site is deemed "important" to the user (visited frequently, bookmarked, etc.)
• Firefox: Shows a browser permission prompt for the user to decide

Since at least one browser prompts the user, we would we need to consider when is the right time to request this and present the right messaging around it.

[bwindels]

Fwiw, the prompt looks like this (triggered from the console here):

[jryans]

We really, really should sort out the UX and try to do this... Every time I see a rageshake from someone's IDB being trashed, I feel the anger from the other side of the tubes, and it feels to the user like Riot has failed them. 😭

[jryans]

@nadonomy, can you think of a good moment in the app lifetime that would make sense to request persistent stoarge (knowing that some browsers will show the user a permission prompt)? This should help massively with storage issues on web.

Here are some possible ideas:

• Add a button in Settings to request manually (not discoverable, only helps users who happen to press it)
• After N days of use, show toast / nag bar / something in app which would request persistent storage from the browser on user approval (so that the possible browser prompt is in context of user action)

[bwindels]

Another suggestion:

• show a dialog "We need to store your keys reliably" or something when joining the first encrypted room.

[nadonomy]

@nadonomy, can you think of a good moment in the app lifetime that would make sense to request persistent stoarge (knowing that some browsers will show the user a permission prompt)? This should help massively with storage issues on web.

I think this really comes down to understanding the browsers intentions better. From the issue, can you clarify Chromes behaviour?

If Chrome only approves "important" sites, can we be deterministic about whether we're important? If we're important does using persistent storage require any user interaction? If we're not, can we still request?

Do we know how Safari behaves?

[bwindels]

Do we know how Safari behaves?

Safari doesn't support persistent storage yet.

[bwindels]

If Chrome only approves "important" sites, can we be deterministic about whether we're important? If we're important does using persistent storage require any user interaction? If we're not, can we still request?

Not sure what their heuristic is, but in any case, Chrome never prompts (only FF does), and instead silently run their heuristic to grant or deny your request for persistent storage. I think it mainly comes down to how much you've used a certain website, with it perhaps becoming a bit more picky if you are short on disk space. If the request is denied though, we're off no worse than we are today.

[jryans]

If Chrome only approves "important" sites, can we be deterministic about whether we're important?

I believe this 2016 annoucement is the most detailed version I've seen, but it's possible it's changed since:

Beginning with Chrome 55, Chrome will automatically grant the persistence permission if any of the following are true:

• The site is bookmarked (and the user has 5 or less bookmarks)
• The site has high site engagement
• The site has been added to home screen
• The site has push notifications enabled

The permission is automatically denied in all other cases.

If we're important does using persistent storage require any user interaction? If we're not, can we still request?

No, for Chrome at least, requesting persistent storage is always silent and we can keep requesting whenever we like.

[jryans]

@ara4n has suggested we could just always request on app load. That's certainly technically easy, but it would mean an immediate permission on load for at least Firefox users, which may push some people away.

We could wait until after you've logged in, which is similarly easy and bit less scary...?

[nadonomy]

Given how different browsers have wildly different interaction models to present to users, I'm kind of inclined to agree that this is the browsers lifting for the most part, rather than ours.

We could wait until after you've logged in, which is similarly easy and bit less scary...?

This seems reasonable.

[jryans]

I have added this to the current phase for E2EE by default, as this issue only becomes more urgent once we have default encrypted rooms.