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.
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.
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.
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