-
Notifications
You must be signed in to change notification settings - Fork 397
MSC3880: dummy replies for Olm #3880
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
base: main
Are you sure you want to change the base?
Conversation
It is up to the client to decide whether and when to send the event. One | ||
possibility is: if the client receives an event over Olm, it waits 2 minutes. | ||
If it has not sent any other event over Olm within those 2 minutes, it will | ||
send an `m.dummy` event. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can Olm libraries expose how many messages have been received since an olm message has been sent in reply and the reply could be tied to a counter instead of some arbitrary timer then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, though I think there may be value in sending a dummy event even after receiving a single olm message. The timer suggested here is just to avoid creating unnecessary traffic, rather than being actually meaningful -- if the client was going to send an event over olm "soon" anyways, then there's no point in sending the dummy event.
FWIW, clients are welcome to encouraged to experiment with different things to see what works best. If you want to try it based on message index, it shouldn't be hard to write a function that returns the information that you need, possibly based on olm_session_describe
. (Unfortunately, I won't have time for at least the next few weeks to write such a function myself.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, right, I guess it makes sense to send a dummy reply in all cases after some time, if the event was not a dummy event itself (or if it is a dummy in a PRE_KEY message). Will be interesting to see, if this causes a lot of additional to_device message traffic.
Rendered