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
There have been some requests going around in the support room of the SDK that people would like to send encrypted to-device events.
While it would be trivial to expose a Device.send_event() method that sets up a Olm Session and allows people to send an event to a particular device, we need to be a bit careful about this.
If the user overuses an OlmSession it may lead to undecryptable messages on the others side. This will only happen in the case of to-device events also arriving out of order, but we don't have strict ordering guarantees for to-device events.
One idea was to use a different OlmSession for room key delivery and one for custom things. This way the room key delivery wouldn't be affected by whatever custom things the user might be doing. This sadly isn't possible since the other side will start using the new custom Session to deliver room keys to us.
Instead we might want to start looking at the message index of the individual Session and decide to rotate in case of overuse.
The text was updated successfully, but these errors were encountered:
There have been some requests going around in the support room of the SDK that people would like to send encrypted to-device events.
While it would be trivial to expose a
Device.send_event()
method that sets up a OlmSession
and allows people to send an event to a particular device, we need to be a bit careful about this.If the user overuses an
OlmSession
it may lead to undecryptable messages on the others side. This will only happen in the case of to-device events also arriving out of order, but we don't have strict ordering guarantees for to-device events.One idea was to use a different
OlmSession
for room key delivery and one for custom things. This way the room key delivery wouldn't be affected by whatever custom things the user might be doing. This sadly isn't possible since the other side will start using the new customSession
to deliver room keys to us.Instead we might want to start looking at the message index of the individual
Session
and decide to rotate in case of overuse.The text was updated successfully, but these errors were encountered: