Skip to content
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

refactor megolm encryption to improve perceived speed #1252

Merged
merged 2 commits into from
Mar 11, 2020

Conversation

uhoreg
Copy link
Member

@uhoreg uhoreg commented Mar 9, 2020

  • allow applications to pre-send decryption keys before the message is sent
  • establish new olm sessions with a shorter timeout first, and then re-try in the background with a longer timeout without blocking message sending

fixes element-hq/element-web#11836

- allow applications to pre-send decryption keys before the message is sent
- establish new olm sessions with a shorter timeout first, and then re-try in
  the background with a longer timeout without blocking message sending
@uhoreg uhoreg requested a review from a team March 9, 2020 22:49
// encryptMessage retries senders in the background before giving
// up and telling them that there's no olm channel, so we need to
// wait a bit before checking that we got the message
setTimeout(resolve, 100);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we use the jest.useFakeTImers() API?
https://jestjs.io/docs/en/timer-mocks

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have some things that use jest timer mocks, but I'm not sure how to use them in the context of waiting for a background task to complete. Though looking at it again, I see a way of doing it without the timer at all.

// already have a session for, and share keys with them. Use a
// shorter timeout when fetching one-time keys.
await this._shareKeyWithDevices(
session, key, payload, devicesWithoutSession, errorDevices, 2000,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

constant?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that it's worth creating a constant for. 🤷‍♂️

* @param {module:models/room} room the room the event is in
*/
MegolmEncryption.prototype.prepareToEncrypt = function(room) {
logger.log(`Preparing to encrypt events for ${this._roomId}`);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this for every message sent? Could get spammy, maybe logger.debug?


if (this.encryptionPreparation) {
// We're already preparing something, so don't do anything else.
// FIXME: check if we need to restart
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, file a task and link here

@uhoreg uhoreg merged commit 86304fd into develop Mar 11, 2020
@t3chguy t3chguy deleted the uhoreg/megolm_speed branch May 10, 2022 14:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Encrypting a fairly straightforward message took >10s to encrypt
2 participants