Skip to content

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

uhoreg
Copy link
Member

@uhoreg uhoreg commented Sep 5, 2022

@uhoreg uhoreg added e2e proposal A matrix spec change proposal kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Sep 5, 2022
@uhoreg uhoreg marked this pull request as ready for review September 5, 2022 16:12
@uhoreg uhoreg changed the title MSCxxxx: dummy replies for Olm MSC3880: dummy replies for Olm Sep 5, 2022
Comment on lines 26 to 29
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.
Copy link
Contributor

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?

Copy link
Member Author

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

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
e2e kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants