Notif panel needs to know how to deal with encrypted room

[AmandineLP]

Today the notification panel is unable to retrieve notifications from encrypted room. This really cripples the experience for people heavily using encryption and needs to be fixed before enabling e2e by default

[aleld]

Are there any Updates on this? For a company environment it is quite important to sustain high grade of communication flow.

[MadLittleMods]

From a discussion out of band, it feels like the notification panel could include client-side mentions since that's how notifications are calculated in E2EE rooms. I assume the client already has enough info to interleave whatever it thinks is a notification to display as a mention in that panel but in order to be 100% correct and have access to all historical notifications we need the following:

@t3chguy noted that the server would need to include the e2ee notify rule results in /notifications so the client could filter them. Which Synapse not doing might be a Synapse bug, the spec is quite open ended but doesn't say anything about excluding them - https://spec.matrix.org/v1.5/client-server-api/#get_matrixclientv3notifications

And with sliding sync, the matrix-js-sdk will only have a fraction of your rooms in memory

---

I just feel like any compromise that's good enough for notifications in e2ee rooms is good enough for that panel.

If I have a notification, I feel like should be able to see it in the panel (applies to any message that is available to the client at that moment). This would be a major step-up.

I understand how it could fall off the list since it's not back-paginated but we can iterate that separately (as noted above)

[davidegirardi]

I think having notifications load up little by little because of sliding sync is not a problem and is kind of expected by an end user. Even if they don't realise how sliding sync works, they are already used to infinite scroll and things loading asynchronously in many other applications.

One sure thing is that the server should be oblivious of any E2EE content, including mentions and other explicit notifications.

[t3chguy]

I think having notifications load up little by little because of sliding sync is not a problem and is kind of expected by an end user. Even if they don't realise how sliding sync works, they are already used to infinite scroll and things loading asynchronously in many other applications.

One sure thing is that the server should be oblivious of any E2EE content, including mentions and other explicit notifications.

They wouldn't load little by little unless you had something backpaginating things like Seshat. Seshat doesn't work in a browser. Seshat also doesn't yet store notifications. The other way would be to mass backpaginate all encrypted rooms when a user scrolls up and stitch timelines but that would likely not be acceptable due to the amount of requests made to the server and how much extra data will get filled into memory

[davidegirardi]

I believed using sliding sync also meant having back pagination but yes, without some kind of storage, it would be taxing on the memory usage.

I don't see the difference with the server though: does it matter if a client backpaginates because of Seshat or something else?

[t3chguy]

Seshat runs intentionally slowly whereas this would ideally backpaginate every of your encrypted rooms at once otherwise the back pagination of the notif panel would be jumpy as things get stitched into the middle

[davidegirardi]

What if Element does the same as Seshat but discards any event without a notification? It will basically backfill until the previous read state and only keep in memory notification information.

[t3chguy]

We'd need to reinvent something like Seshat (which doesn't support web) to store it in, otherwise it has to be re-loaded every time you reload the app or update it. Its definitely possible but the experience for backpaginating the panel would be very slow and jumpy.

[davidegirardi]

Can't we use the localStorage to keep the encrypted events and then get them from there?

[t3chguy]

We already store too much in localStorage, often hitting quotas. IDB would be a better option. But you'd also need to handle redactions, periodically checking back on all those stored events to see if they got redacted.

[dkasak]

I think the proper solution would be to make Seshat work in Element Web (I think the only issue is that the tantivy dependency doesn't support it) and then have it expose an API specifically for notifications, similar to the C2S /notifications one. IMO, the right approach is to stop considering Seshat as simply a search module but more of a general-purpose client-side message store which can implement many of the traditionally server-side APIs which cannot be done server-side in encrypted contexts.

[davidegirardi]

Doing that would solve a lot of problems like having a list of your threads and similar. Where can we store the data if we are already hitting the limits on localStorage?

[richvdh]

Where can we store the data if we are already hitting the limits on localStorage?

IndexedDB.

[opeik]

As an occasional user of Element, not having notifications makes the app borderline unusable for async communication.