- May 21, 2024
-
-
-
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.
-
- May 17, 2024
-
-
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
-
Signed-off-by:strawberry <strawberry@puppygock.gay>
-
Signed-off-by: -
-
- May 15, 2024
-
-
-
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
the namespace check on username login is unnecessary, hashes aren't ever going to match, and axum auth handles this kind of stuff already Signed-off-by: -
we now pass all Content-Disposition checks/tests Signed-off-by: -
https://github.com/matrix-org/complement/pull/723 • Updated input 'complement': 'github:matrix-org/complement/370a014dca0f720614e0c8f68b9a3e66ecf7f516' (2024-05-02) → 'github:matrix-org/complement/8587fb3cbe746754b2c883ff6c818ca4d987d0a5' (2024-05-14) Signed-off-by:
-
debconf support needs to be done in a way that does not duplicate the config file like upstream does. Signed-off-by: -
the language here is very poor and i'm not sure why it was written like this. Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
this allows build to be ran for workflow_dispatch Signed-off-by: -
Signed-off-by: -
Signed-off-by:
-
- May 12, 2024
-
-
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
upload complement OCI image from CI, document where it can be found, use `main` instead of `dev` for tag Signed-off-by: -
Signed-off-by: -
• Updated input 'complement': 'github:matrix-org/complement/891d18872c153d39a9ce63b545045efddb845738' (2024-04-30) → 'github:matrix-org/complement/370a014dca0f720614e0c8f68b9a3e66ecf7f516' (2024-05-02) • Updated input 'crane': 'github:ipetkov/crane/f6c6a2fb1b8bd9b65d65ca9342dd0eb180a63f11' (2024-04-21) → 'github:ipetkov/crane/27025ab71bdca30e7ed0a16c88fd74c5970fc7f5' (2024-05-09) • Updated input 'fenix': 'github:nix-community/fenix/73124e1356bde9411b163d636b39fe4804b7ca45' (2024-05-01) → 'github:nix-community/fenix/297c756ba6249d483c1dafe42378560458842173' (2024-05-10) • Updated input 'fenix/rust-analyzer-src': 'github:rust-lang/rust-analyzer/55d9a533b309119c8acd13061581b43ae8840823' (2024-04-20) → 'github:rust-lang/rust-analyzer/5bf2f85c8054d80424899fa581db1b192230efb5' (2024-05-09) • Updated input 'nixpkgs': 'github:NixOS/nixpkgs/5c24cf2f0a12ad855f444c30b2421d044120c66f' (2024-04-19) → 'github:NixOS/nixpkgs/f1010e0469db743d14519a1efd37e23f8513d714' (2024-05-09) Signed-off-by: -
Signed-off-by: -
Signed-off-by:
-
- May 11, 2024
-
-
Signed-off-by:
-
![renovate[bot]'s avatar](https://secure.gravatar.com/avatar/4836c036306c20663d397df5cd0c2046c486c5ce1327af904affd8d285099e24?s=64&d=identicon "renovate[bot]")