Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
  • renovate/nixos-nix-2.x
  • renovate/axum-monorepo
  • morguldir/rocky
  • github/fork/JadedBlueEyes/images
  • github/fork/JadedBlueEyes/federation-allow-list
  • renovate/itertools-0.x
  • renovate/sentry-rust-monorepo
  • renovate/lock-file-maintenance
  • renovate/axum-client-ip-0.x
  • renovate/tokio-tracing-monorepo
  • renovate/opentelemetry-rust-monorepo
  • renovate/hyper-util-0.x
  • renovate/nix-community-cache-nix-action-5.x
  • morguldir/snake-sync
  • strawberry/maybe-knocking
  • strawberry/pr-660-presence-fix
  • github/fork/JadedBlueEyes/dockerhub-description
  • strawberry/morgs-snake-sync-jason-main
  • github/fork/bumpsoo/main
  • v0.5.0-rc2
  • v0.5.0-rc
  • v0.4.7-rc
  • v0.4.6
  • v0.4.6-rc
  • v0.4.5
  • v0.4.5-rc
  • v0.4.4
  • v0.4.3
  • v0.4.2
  • v0.4.1
  • v0.3.4
  • v0.3.3
  • v0.3.2
  • v0.3.1
  • v0.3.0
36 results
Search by author
  • Any Author
  • 🥺 🥺 june
1 author
  1. Jul 27, 2024
  3. Jul 14, 2024
  5. Jul 13, 2024
  7. Jul 08, 2024
  9. Jul 03, 2024
  11. Jun 18, 2024
  13. Jun 16, 2024
  15. Jun 14, 2024
  17. Jun 10, 2024
  19. Jun 09, 2024
  21. Jun 06, 2024
  23. Jun 03, 2024
  25. Jun 02, 2024
  27. May 27, 2024
  29. May 26, 2024
  31. May 22, 2024
  33. May 21, 2024
    • Benjamin Lee's avatar
      don't return extra member count or e2ee device updates from sync · 9eb0784f
      Benjamin Lee authored and 🥺's avatar 🥺 committed 
      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]: https://github.com/girlbossceo/conduwuit/issues/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.
      9eb0784f
  35. May 17, 2024
    • Benjamin Lee's avatar
      remove sync response cache · 8bffcfe8
      Benjamin Lee authored and 🥺's avatar 🥺 committed 
      This cache can serve invalid responses, and has an extremely low hit
rate.

It serves invalid responses because because it's only keyed off
the `since` parameter, but many of the other request parameters also
affect the response or it's side effects. This will become worse once we
implement filtering, because there will be a wider space of parameters
with different responses. This problem is fixable, but not worth it
because of the low hit rate.

The low hit rate is because normal clients will always issue the next
sync request with `since` set to the `prev_batch` value of the previous
response. The only time we expect to see multiple requests with the same
`since` is when the response is empty, but we don't cache empty
responses.

This was confirmed experimentally by logging cache hits and misses over
15 minutes with a wide variety of clients. This test was run on
matrix.computer.surgery, which has only a few active users, but a
large volume of sync traffic from many rooms. Over the test period, we
had 3 hits and 5309 misses. All hits occurred in the first minute, so I
suspect that they had something to do with client recovery from an
offline state. The clients that were connected during the test are:

 - element web
 - schildichat web
 - iamb
 - gomuks
 - nheko
 - fractal
 - fluffychat web
 - fluffychat android
 - cinny web
 - element android
 - element X android

Fixes: #336
      8bffcfe8
  37. May 06, 2024
  39. May 03, 2024
  41. Apr 26, 2024
  43. Apr 17, 2024
  45. Apr 09, 2024
  47. Apr 06, 2024
  49. Apr 03, 2024
  51. Apr 02, 2024
  53. Mar 31, 2024
  55. Mar 27, 2024