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
Historically the crypto SDK have been using the key backup only to get all the keys at once. This strategy is not very efficient, particularly for huge backups, where the backup download and decryption would take *minutes to get the keys (and was jaming some legacy sdks, blocking sending message).
Recent changes on web and android have been introduced to query the backup incrementally. This mechanism greatly improves the user experience and speed to get messages.
I was trying to use the same strategy in Element R, and it's a bit hacky to intercept the key requests (can be done in RequestSender#sendToDevice). But most annoyingly the strategy to use key backup would be duplicated in all Element R's.
I wonder if it wouldn't make sense to integrate this functionality into the crypto crate.
It would also benefit to EX, and I think it make sense to integrate it as part of the Gossip Machine.
Here is some reference chart of how it was integrated in legacy clients:
This mechanism can be greatly improved, and it would be nice to have it done once for all clients.
Some open questions, possible improvements:
Should we priorize checking backup other sending to devices or do it in parallel? Might be good to reduce to device traffic due to key gossiping
Some sort of batch/bulk? If we see a lot of request for sessions in the same room, it might be smart at some point to download all sessions for the room?
After successful self verification, it might be a good idea to start background work to download keys for the most recent rooms (or recent messages of each of the recent rooms).
The text was updated successfully, but these errors were encountered:
Related to element-hq/element-meta#757
Historically the crypto SDK have been using the key backup only to get all the keys at once. This strategy is not very efficient, particularly for huge backups, where the backup download and decryption would take *minutes to get the keys (and was jaming some legacy sdks, blocking sending message).
Recent changes on web and android have been introduced to query the backup incrementally. This mechanism greatly improves the user experience and speed to get messages.
I was trying to use the same strategy in Element R, and it's a bit hacky to intercept the key requests (can be done in RequestSender#sendToDevice). But most annoyingly the strategy to use key backup would be duplicated in all Element R's.
I wonder if it wouldn't make sense to integrate this functionality into the crypto crate.
It would also benefit to EX, and I think it make sense to integrate it as part of the Gossip Machine.
Here is some reference chart of how it was integrated in legacy clients:
This mechanism can be greatly improved, and it would be nice to have it done once for all clients.
Some open questions, possible improvements:
The text was updated successfully, but these errors were encountered: