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

Bugfix: don't return extra member count or e2ee device updates from sync #389

Merged
merged 1 commit into from
May 21, 2024

Conversation

olivia-fl
Copy link
Contributor

Previously, we were returning redundant member count updates or encrypted device updates from the /sync endpoint in some cases. The extra member count updates are spec-compliant, but unnecessary, while the extra encrypted device updates violate the spec.

The refactor necessary to fix this bug is also necessary to support filtering on state events in sync.

Details

Joined room incremental sync needs to examine state events for four purposes:

  1. determining whether we need to return an update to room member counts
  2. determining the set of left/joined devices for encrypted rooms (returned in device_lists)
  3. returning state events to the client (in rooms.joined.*.state)
  4. tracking which member events we have sent to the client, so they can be omitted on future requests when lazy-loading is enabled.

The state events that we need to examine for the first two cases is member events in the delta between since and the end of timeline. For the second two cases, we need the delta between since and the start of timeline, plus contextual member events for any senders that occur in timeline. The second list is subject to filtering, while the first is not.

Before this change, we were using the same set of state events that we are returning to the client (cases 3/4) to do the analysis for cases 1/2. In a compliant implementation, this would result in us missing some relevant member events in 1/2 in addition to seeing redundant member events. In current conduwuit this is not the case because the set of events that we return to the client is always a superset of the set that is needed for cases 1/2. This is because we don't support filtering, and we have an existing bug where we are returning the delta between since and the end of timeline rather than the start.

Fixing this is necessary to implement filtering because otherwise we would start missing some member events for member count or encrypted device updates if the relevant member events are rejected by the filter. This would be much worse than our current behavior.

Previously, we were returning redundant member count updates or encrypted
device updates from the /sync endpoint in some cases. The extra member
count updates are spec-compliant, but unnecessary, while the extra
encrypted device updates violate the spec.

The refactor necessary to fix this bug is also necessary to support
filtering on state events in sync.

Details:

Joined room incremental sync needs to examine state events for four
purposes:

 1. determining whether we need to return an update to room member counts
 2. determining the set of left/joined devices for encrypted rooms
    (returned in `device_lists`)
 3. returning state events to the client (in `rooms.joined.*.state`)
 4. tracking which member events we have sent to the client, so they can
    be omitted on future requests when lazy-loading is enabled.

The state events that we need to examine for the first two cases is member
events in the delta between `since` and the end of `timeline`. For the
second two cases, we need the delta between `since` and the start of
`timeline`, plus contextual member events for any senders that occur in
`timeline`. The second list is subject to filtering, while the first is
not.

Before this change, we were using the same set of state events that we are
returning to the client (cases 3/4) to do the analysis for cases 1/2.
In a compliant implementation, this would result in us missing some
relevant member events in 1/2 in addition to seeing redundant member
events. In current conduwuit this is not the case because the set of
events that we return to the client is always a superset of the set that
is needed for cases 1/2. This is because we don't support filtering, and
we have an existing bug[1] where we are returning the delta between
`since` and the end of `timeline` rather than the start.

[1]: girlbossceo#361

Fixing this is necessary to implement filtering because otherwise
we would start missing some member events for member count or encrypted
device updates if the relevant member events are rejected by the filter.
This would be much worse than our current behavior.
@girlbossceo girlbossceo merged commit 9eb0784 into girlbossceo:main May 21, 2024
8 checks passed
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.

2 participants